REQUIREMENTS ANALYSIS SYSTEM AND REQUIREMENTS ANALYSIS PROCEDURES

The requirements analysis system addresses the issue of inaccurate topic classification by using a hierarchical dictionary and training data fitting unit to enhance the classification model's accuracy in assigning topics to new requirements, reducing manual effort and improving classification performance.

DE112023006359T5Pending Publication Date: 2026-04-30ASTEMO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
DE112023006359
Authority / Receiving Office
DE · DE
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-07-19
Publication Date
2026-04-30

AI Technical Summary

Technical Problem

Existing machine learning-based classification systems for customer requirements suffer from accuracy deterioration due to missing training data and varying requirement granularity across customers, making it difficult to accurately classify and reuse topics.

Method used

A requirements analysis system that includes a requirements topic database, hierarchical dictionary, and training data fitting unit to extract subordinate topics, creating a classification model that assigns suitable topics to new requirements based on existing data, using a hierarchical structure to improve classification accuracy.

Benefits of technology

Enhances the accuracy of topic classification by adapting training data, allowing for efficient and accurate assignment of topics to new requirements, reducing manual effort and improving the classification model's performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A requirements analysis system outputs an existing requirement, to which a topic is assigned, as training data. The number of first requirements, to which at least one is assigned by a topic and a sub-topic, is greater than or equal to a threshold. This training data is used to train a classification model that assigns topic candidates to at least a second requirement, described in a second document as the analysis target, and in which the number of topics is adjusted. The system receives the training data to create the classification model, feeds the second requirement into the classification model, assigns topic candidates to the second requirement, and assigns sub-topics to the second requirement for each topic candidate, in relation to the topic candidates obtained from the hierarchical dictionary.
Need to check novelty before this filing date? Find Prior Art

Description

Technical field

[0001] The present invention relates to a requirements analysis system and a requirements analysis method. background

[0002] Since customers have various requirements during product development, product developers must analyze these requirements and identify the desired features. For example, a developer might determine which requirement classifies a product's function as a development unit, or assign a property to the product as specified in the requirement and identify the difference between the product and an existing one. In this way, the developer has analyzed the customer's requirements. However, because customer requirements are often described in various documents or documents with many pages, the analytical work, for which machine learning is applied, is increasingly being automated to analyze customer requirements more quickly and accurately than before.

[0003] To automatically identify and classify features related to customer requirements and their attributes, a classification algorithm must be trained using machine learning. To improve the accuracy of this automatic classification, it is necessary to create training data where classification result information is correctly mapped to a requirement. This classification result information represents the outcome of classifying features or attributes (referred to as "topics" in the following description) in relation to previously stated requirements.

[0004] PTL 1 describes that "a learning device assigns a label to each word used to classify clusters when the device classifies multiple documents into groups using words contained in the documents. The learning device classifies the multiple documents into clusters by using the label assigned to each word. In a case where the cluster in which classification is performed using a first word is similar to the cluster in which classification is performed using a second word, the learning device assigns the second label a label that matches the label assigned to the first word." Citation list for patent literature

[0005] PTL 1: JP 2018-169940 A Overview of the invention Technical problem

[0006] Furthermore, if a significant portion of the training data is missing, the accuracy of the automatic classification deteriorates, and consequently, the classification algorithm delivers an incorrect classification decision. In this case, customer requirements cannot be correctly classified because the machine learning-based classification of the topics is flawed. Additionally, as the topics become more detailed, while their meanings become clearer, the number of documents with common topics—that is, the number of customer requirements—decreases.For this reason, it is necessary to provide a workaround that causes a machine learning system to learn content classified by a user (for example, a developer) as part of their daily work and to feed the learning data back to the automatic classification system, but traditionally, learning has not been carried out from this perspective.

[0007] Furthermore, the topic of a requirement changes depending on the customer and the development projects themselves. For example, Customer A might define requirements in detail, while Customer B only defines them down to a basic level. Because the granularity of a requirement varies from customer to customer, as described above, it was difficult to specify a topic for reuse or new creation simply by comparing requirements based on their similarity to existing ones. Additionally, PTL 1 describes how a variety of words with assigned labels can be integrated into a cluster, but it is difficult to automatically classify topics through such integration alone.

[0008] The present invention was made with such a situation in mind, and one objective of it is to adapt the training data used to learn a classification model for classifying a requirement, to assign a suitable topic to a requirement, and to classify the requirement. Solution to the problem

[0009] A requirements analysis system of the present invention comprises a requirements topic database that stores at least one first requirement described in a first document and a topic associated with the at least one first requirement, a hierarchical dictionary that stores several of the topics together with levels of detail representing a hierarchical structure of the topics, a training data fitting unit that extracts subordinate topics belonging to a hierarchy below the topics associated with the at least one first requirement, based on the at least one first requirement obtained from the requirements topic database, the topics associated with the at least one first requirement, and the hierarchical dictionary, which contains the topics associated with the at least one first requirement.the number of subtopics assigned to each subtopic is greater than or equal to a threshold, as training data used to train a classification model that assigns candidates of the topics to at least a second requirement described in a second document as the analysis target, outputs a number of the topics fitted, a training unit that receives the training data and creates the classification model, a topic candidate assignment unit that feeds the at least one second requirement into the classification model and assigns the candidates of the topics to the at least one second requirement, and a topic assignment unit that assigns the subtopics obtained from the hierarchical dictionary to the candidates of the topics to which the candidates of the topics are assigned. Advantageous effects of the invention

[0010] According to the present invention, the classification model created by adapting the training data used for learning the classification model can assign the subordinate topics to the topic candidates associated with the second requirement and classify the requirements. Brief description of the drawings [ Fig. 1] Fig. Figure 1 is a block diagram showing a hardware configuration example of a requirements analysis system according to an embodiment of the present invention. [ Fig. 2] Fig. Figure 2 is a block diagram showing an example of the functional configuration of the requirements analysis system according to an embodiment of the present invention. [ Fig. 3] Fig. Figure 3 is a diagram showing a configuration example of a request topic screen displayed on a display device by a display input unit according to an embodiment of the present invention. [ Fig. 4] Fig. Figure 4 is a flowchart showing an example of processing a requirements analysis program according to an embodiment of the present invention. [ Fig. 5] Fig. Figure 5 is a diagram that represents a configuration example of a requirements topic database containing topics that are assigned to requirements of an existing project, according to an embodiment of the present invention. [ Fig. 6] Fig. Figure 6 is a diagram that shows a configuration example of a hierarchical dictionary according to an embodiment of the present invention. [ Fig. 7] Fig. Figure 7 is a diagram illustrating a relationship between a hierarchical structure of topics and a level of detail according to an embodiment of the present invention. [ Fig. 8] Fig. Figure 8 is a flowchart illustrating an example of processing in a learning data fitting unit according to an embodiment of the present invention. [ Fig. 9] Fig. Figure 9 is a diagram showing a calculation result of the number of requirements for each topic ID according to an embodiment of the present invention. [ Fig. 10] Fig. Figure 10 is a diagram showing an example where a portion of the requirements topic DB is extracted, as well as an example of a portion of training data according to an embodiment of the present invention. [ Fig. 11] Fig. Figure 11 is a diagram illustrating a configuration example for analysis target requirements according to an embodiment of the present invention. [ Fig. 12] Fig. Figure 12 is a diagram illustrating a configuration example for requirement + topic candidate (automatically) according to an embodiment of the present invention. [ Fig. 13] Fig. 13 is a flowchart illustrating an example of processing to output requirement + topic candidate (automatically + dictionary) according to an embodiment of the present invention. [ Fig. 14] Fig. Figure 14 is a diagram illustrating configuration examples for the requirement + the topic candidate (automatic) and the requirement + the topic candidate (automatic + dictionary) according to an embodiment of the present invention. [ Fig. 15] Fig. Figure 15 is a diagram showing a configuration example for the requirement topic database, which contains topics that are assigned to requirements of new projects, according to an embodiment of the present invention. [ Fig. 16] Fig. Figure 16 is a diagram showing an example of a theme difference display screen displayed by the display input unit on the display device, according to an embodiment of the present invention. [ Fig. 17] Fig. Figure 17 is a flowchart showing an example (first half) of processing in a topic difference comparison unit according to an embodiment of the present invention. [ Fig. 18] Fig. Figure 18 is a flowchart showing an example (second half) of processing in the topic difference comparison unit according to an embodiment of the present invention. [ Fig. 19] Fig. Figure 19 is a diagram illustrating a process for creating a topic comparison list according to an embodiment of the present invention. Description of embodiments

[0011] The following describes embodiments of the present invention with reference to the accompanying drawings. In this description and the drawings, components with substantially identical function or configuration are designated by the same reference numerals, and redundant descriptions are omitted. [First embodiment<Hardwarekonfigurationsbeispiel eines Anforderungsanalysesystems>

[0012] First, a hardware configuration example for a requirements analysis system 1 is presented with reference to Fig. 1 described.

[0013] Fig. Figure 1 is a block diagram illustrating the hardware configuration example of the requirements analysis system 1 according to an embodiment of the present invention.

[0014] The requirements analysis system 1 comprises a client personal computer (PC) 10 and a requirements analysis server 20. The client PC 10 and the requirements analysis server 20 form a server-client system. For example, the client PC 10 can access the locally installed requirements analysis server 20 via a communication channel such as a local area network (LAN). However, the requirements analysis server 20 can also be a virtual machine in a cloud. In this case, the client PC 10 can access the requirements analysis server 20 via an external network such as the internet. Furthermore, the client PC 10 can also review a classification result of the requirements analysis by the requirements analysis server 20 via a web browser in a format that only includes the input device 17 and the display device 18.

[0015] First, an example of the internal configuration of client PC 10 is described.

[0016] The client PC 10 contains a random access memory (CPU) 11, a random access memory (RAM) 12, a memory 13, a read-only memory (ROM) 14, a network interface 16, an input device 17 and a display device 18.

[0017] The CPU 11 reads program code (for example, the requirements analysis tool 15) from ROM 14 to implement each function according to the present embodiment, loads the program into RAM 12, and executes the program. Variables, parameters, and the like that generated during the CPU 11's processing are temporarily written to RAM 12, and these variables, parameters, and the like are read by the CPU 11 in a suitable manner. The requirements analysis tool 15 is a software program that can be executed by the client PC 10 and can instruct the requirements analysis server 20 to perform a requirements analysis. Furthermore, the requirements analysis tool 15 provides a user interface through which a user can enter data or check the screen.

[0018] In memory 13, which is a non-volatile storage medium, a program that causes the client PC 10 to operate is recorded, in addition to an operating system (OS) and various parameters. Memory 13 can be, for example, a hard disk drive (HDD), a solid-state drive (SSD), or non-volatile memory. Memory 13 and ROM 14 contain programs, data, and the like that are required for the CPU 11 to operate and are used as an example of a non-volatile, computer-readable storage medium containing a program to be executed by the client PC 10.

[0019] For example, a network interface card (NIC) is used as network interface 16, and various data can be sent to and received from the requirements analysis server 20 via a LAN connected to a port of the NIC, a leased line, an Internet communication path, or the like.

[0020] Input device 17, for example, uses a keyboard and a mouse, allowing the user to enter predefined instructions and issue commands. Display device 18, for example, is a liquid crystal display monitor and shows the user the result of processing performed by the client PC 10 and the like.

[0021] Next, an example of the internal configuration of the requirements analysis server 20 is described.

[0022] The requirements analysis server 20 contains a server CPU 21, a server RAM 22, a server memory 23, a server network interface 24 and a server ROM 25.

[0023] The server CPU 21 reads program code (for example, a requirements analysis program 26) of software for implementing each function according to the present embodiment from the server ROM 25, loads the program into the server RAM 22, and executes the program. Variables, parameters, and the like that generated during the processing of the server CPU 21 are temporarily written to the server RAM 22, and these variables, parameters, and the like are read by the server CPU 21 in a suitable manner. The requirements analysis program 26 is a software program that can be executed by the requirements analysis server 20 and performs various functions that are subsequently defined according to the Fig. The present embodiment, as described in section 2, provides this functionality. For example, both existing and new projects contain many documents, and each document has multiple defined requirements. Therefore, the requirements analysis program 26 counts the number of requirements regardless of the document's page count and extracts topics from the counted requirements. A topic is, for example, a keyword, annotation, or a note associated with a document containing described requirements.

[0024] The server memory 23, which is a non-volatile storage medium, contains, in addition to an operating system (OS) and various parameters, a program that causes the requirements analysis server 20 to operate. Server memory 23 can be, for example, an HDD, an SSD, or other non-volatile storage medium. Server memory 23 and server ROM 25 contain programs, data, and similar items required for the server CPU 21 to operate and are used as an example of a non-volatile, machine-readable storage medium containing a program to be executed by the requirements analysis server 20.

[0025] For example, a NIC is used as a server network interface 24, and various data can be sent to and received from the client PC 10 via a LAN connected to a port of the NIC, a leased line, an Internet communication path, or the like.

[0026] Note that, although Fig. Figure 1 shows that, where the requirements analysis system 1 contains the client PC 10 and the requirements analysis server 20, the functionality of the requirements analysis server 20 can be integrated into a client PC 10. In this case, the client PC 10 is configured as a standalone device, and the requirements analysis tool 15 has a function of the requirements analysis program 26. <Beispiel für die funktionale Konfiguration des Anforderungsanalysesystems>

[0027] Next, an example of the functional configuration of the requirements analysis system 1 will be given with reference to Fig. 2 described.

[0028] Fig. Figure 2 is a block diagram illustrating the example of the functional configuration of the requirements analysis system 1. The content of the diagram shown in Figure 2 is shown in Figure 2. Fig. The two function blocks shown are described with reference to Fig. 3 and the following drawings are described. Note that each in Fig. 2 function block shown in which in Fig. The requirements analysis program 26 shown in section 1 is configured, and each database in which it is configured is configured. Fig. The server storage 23 shown in section 1 is configured. Furthermore, various types of data generated in the respective function blocks are temporarily stored in the space shown in Fig. The server RAM 22 shown in the diagram is stored and read as needed.

[0029] The requirements analysis system 1 contains a topic mapping unit 201, a topic difference comparison unit 202, a learning data adaptation unit 203, a classification model learning unit 204, an evaluation unit 205, a display input unit 206, a requirements topic database (DB) 221, and a hierarchical dictionary 222. Between the functional units, an analysis target requirement 211, a requirement + a topic candidate (auto) 212, a requirement + a topic candidate (auto + dictionary) 213, a requirement 214 for which a topic has been determined, and a difference 215 between new and existing requirements are generated.

[0030] An existing requirement is a customer requirement that was fulfilled in a previous project. Topics with different levels of detail are assigned to existing requirements based on a design outcome. Therefore, the requirements analysis system 1 can use existing requirements as training data for the classification model. A new requirement, on the other hand, is a customer requirement to be fulfilled in a new project and has no assigned topic. Therefore, the new requirement is a goal for which the requirements analysis system 1 automatically classifies topics using the classification model and is also referred to as an analysis goal requirement.

[0031] The display input unit 206 causes the client PC 10 to display a screen on which a user can enter input. For this purpose, the display input unit 206 creates screen data that constitutes the screen and sends the screen data to the client PC 10 via the server network interface 24. Upon receiving the screen data via network interface 16, the requirements analysis tool 15 of the client PC 10 displays a requirements topic screen 30 based on the screen data (see Fig. 3) and a theme difference display screen 40 (see Fig. 16), which are described later, on the display unit 18. Furthermore, the display input unit 206 forwards an instruction entered via the screen to the requirements analysis tool 15. The requirements analysis tool 15 outputs the user's instruction to the requirements analysis server 20 via the network interface 16. The requirements analysis server 20 outputs the instruction received via the server network interface 24 to the display input unit 206, and the display input unit 206 outputs the instruction to a required function block according to the instruction.

[0032] The display input unit (display input unit 206) shows topic candidates on the requirement topic screen 30 according to detail levels and in priority order. Upon receiving a topic assignment operation to replace a topic candidate with another topic, the display input unit outputs a second requirement (new requirement: e.g., the analysis objective requirement 211) to the evaluation unit 205, in which the topic candidate has been replaced by another topic.

[0033] Fig. Figure 3 is a diagram showing a configuration example of the requirement topic screen 30 displayed by the display input unit 206 on the display device 18. The requirement topic screen 30 contains an input section for a new project ID 31, a reading section 32 for the analysis target requirement, a topic assignment completion section 33, and a requirement topic display section 34.

[0034] When a user specifies a new project ID, they enter the new project ID in input field 31 for the new project ID. For example, the new project ID might be P2, and the new project contains the new requirement described above. When the user then clicks on reading field 32 for the analysis target requirement, it reads the new project ID. Fig. Figure 1 shows a requirements analysis program 26 with a requirements file from the requirements topic database 221. The requirements file resembles a field configuration of the requirements topic database 221. The requirements topic database 221 is an example of a database that contains one or more existing requirements described in an existing document (first document), as well as topics associated with the existing requirement (first requirement).

[0035] As described above, the existing document is an example of the first document used in a previous project P1 (see Fig. 5), and the new document is an example of the second document used in the new project P2. Furthermore, the “analysis target requirement” of reading section 32 for the analysis target requirement corresponds to the new requirement described above and represents a process in which the user considers which topic should be assigned to a new customer requirement.

[0036] The requirement topic display section 34 contains fields for a requirement ID, a requirement set, multiple topic IDs, and a candidate for automatically classifying a requirement file read from the requirement topic database 221. Topics are managed in a hierarchical structure, where a topic with a parent content has a detail level of 1, and a topic with the next higher content has a detail level of 2. Topic ID 34-1 stores the topic ID of the topic at detail level 1. The topic ID of the topic at detail level 2 is stored in Topic ID 34-2, and the topic ID of the topic at detail level 3 is stored in Topic ID 34-3. Topics with detail levels 2 and above are also referred to as "detailed topics."

[0037] For example, the first data record from the top is a record containing a requirement for an inverter system. The requirement ID is R1, the requirement set is "The inverter system should control the electric motor torque," the topic ID 34-1 refers to topic T1 at detail level 1, the topic ID 34-2 refers to topics T1-1 and T1-2 at detail level 2, and the topic ID 34-3 refers to topics T1-1-1, ... at detail level 3. In the following description, a "requirement set" can be referred to as a "requirement." Furthermore, requirement R1 is an existing requirement in the existing project P1 (an example of the first requirement).

[0038] The user can select a topic at each detail level from a drop-down list provided in the topic ID field. For example, from the drop-down list for topic "T1" at detail level 1, the user can select one of the following options: "T1: Torque Control," "T2: Wake-up," and "T3: Speed ​​Control." Similarly, for topic at detail level 2 and topic at detail level 3, the user can select detailed topics from the drop-down lists. These detailed topics, with their respective detail levels, contain content that corresponds to the information described later. Fig. 2 and Fig. 6 depicted hierarchical dictionary 222 correspond.

[0039] In the candidate field for automatic classification, a display instruction section 36 is provided, and this section serves to display a topic candidate display section 37, which is overlaid on the requirement topic screen 30 by the user clicking it. When the user clicks on display instruction section 36, the requirements analysis system 1 performs a preliminary analysis, and the classified topic candidates are displayed in the topic candidate display section 37 in order of priority. The priority is determined by the accuracy of the automatic classification, a low number of topic candidates classified by the hierarchical dictionary 222, and similar factors.The hierarchical dictionary (hierarchical dictionary 222) is an example of a database that contains several topics together at the levels of detail that represent the hierarchical structure of the topics, and the hierarchical dictionary 222 defines the hierarchy to which the topics belong.

[0040] Although the topic IDs are displayed in the topic candidate display section 37, the content of the topics linked to each topic ID (see the section described later) may vary. Fig. 6). If the user selects a topic from the topic candidates displayed in the requirement topic display section 34, the selected topic is automatically displayed in the row where the user clicks on the display instruction section 36. For example, in the record of the topic ID whose requirement ID is R2, "T1: Torque Control," "T2: Wake-up," and "T3: Speed ​​Control" are displayed as automatic classification results in the drop-down list. Requirement R2 is designated as a new requirement (example of the second requirement) of the new project P2. If the user selects "T2: Wake-up," subordinate detailed topics (topics T2-1 and T2-1-1) of topic T2 are displayed as topic candidates. The hierarchy to which topics can be automatically classified depends on a calculated accuracy value of the automatic classification and the number of documents used for training.

[0041] The assessment unit 205 is an example of the topic candidate assignment unit, which feeds the second requirement (new requirement) into the classification model (classification model 204a) and assigns topic candidates to the second requirement (new requirement).

[0042] Furthermore, the evaluation unit 205 feeds the new requirement, whose topic candidate has been replaced by another topic, back into the classification model 204a. The classification model 204a, which assigns the topic candidate selected by the classification model 204a to the new requirement, has the function of classifying and assigning the topic candidate to the new requirement based on a keyword or similar term described in the new requirement upon receipt of the new requirement. The new requirement to which the topic candidate is assigned is then displayed again on the requirement topic screen 30.

[0043] Once the topic selection for the requirement is complete, the user clicks on the topic assignment completion section 33. When the user clicks on the topic assignment completion section 33, the display input unit 206 receives a completion instruction for the topic assignment operation. Upon receiving the completion instruction for the topic assignment operation, the display input unit 206 stores a combination of the new requirement and the topic candidate assigned to the new requirement in the requirement topic database 221. With this configuration of the requirement topic screen 30, it is easy for the user to classify topics for efficient requirements analysis, and for the requirements analysis program 26 to repeatedly learn and automatically classify topics.

[0044] Traditionally, users had to learn classified content as training data during their daily work and feed this training data back to the automatic classification system. However, when users assign topics, the man-hours required to analyze the requirements of new projects increase, and therefore, additional work solely for topic assignment is inappropriate. To address this problem, the requirements analysis system 1 presents users with corresponding, less detailed topic candidates via the requirements topic screen 30, using the hierarchical dictionary 222, based on the results of the automatic topic classification in the higher hierarchy. Therefore, in addition to classifying requirements by topic, users can easily assign more detailed topics to the requirements. <Beispiel für das Verarbeiten des Anforderungsanalyseprogramms>

[0045] Next, an example of processing the requirements analysis program 26 will be given with reference to the Fig. 2 and Fig. 4 described.

[0046] Fig. Figure 4 is a flowchart that shows an example of processing the requirements analysis program 26. This flowchart serves to describe a requirements analysis procedure that is carried out in the requirements analysis system 1.

[0047] First, the learning data adaptation unit 203 begins learning upon detecting that the requirements topic database 221 has been updated, and generates learning data 203a (S1). This learning data 203a is then output to the classification model learning unit 204. Note that a trigger for starting the learning process can be an explicit user-entered instruction. Details of the processing in step S1 will be discussed later with reference to... Fig. 8 described.

[0048] Next, the learning unit (Classification Model Learning Unit 204) performs learning on the classification model (Classification Model 204a) using the learning data (Learning Data 203a) as input (S2). Note that the Classification Model Learning Unit 204 performing the learning on Classification Model 204a is equivalent to creating Classification Model 204a. Classification Model 204a is then output to the assessment unit 205.

[0049] The learning data 203a can be recorded in the requirement topic database 221. In this case, the classification model learning unit 204 can read the learning data 203a from the requirement topic database 221 and provide it to the classification model 204a for learning.

[0050] Next, the evaluation unit 205 feeds a new requirement into the classification model 204a, thereby outputting the new requirement to which the classification model 204a has assigned topic candidates. For example, the evaluation unit 205 begins upon receiving an input of the analysis target requirement 211, which is accessed by clicking on reading section 32 for the analysis target requirement on the [unclear text]. Fig. The process begins with the creation of the requirement topic screen 30 shown in Figure 3, followed by the analysis of the analysis target requirement 211 using the classification model 204a. The evaluation unit 205 then automatically assigns the topic candidates to the analysis target requirement 211 using the classification model 204a (S3). This process, in which the classification model 204a automatically assigns the topic candidates to the analysis target requirement 211, is referred to as "evaluation." Note that in the section described later... Fig. 12. The topic candidate is represented by a topic ID candidate.

[0051] The analysis target requirement 211, to which the topic candidates are automatically assigned, is output as the requirement + the topic candidate (auto) 212 to the topic assignment unit 201. The topic candidates (auto) are topic candidates that are automatically assigned to the requirements stored in the analysis target requirement 211 by the classification model 204a.

[0052] Next, for each topic candidate, the topic mapping unit 201 assigns a sub-topic (detailed topic) to the second requirement (new requirement) to which each topic candidate is assigned, based on the hierarchical dictionary 222. For example, the topic mapping unit 201 determines detailed topics for the requirement + topic candidate (auto) 212 based on topic information 222a read from the hierarchical dictionary 222. The topic mapping unit 201 adds the topic candidates and topic information to the requirement + topic candidate (auto) 212 (S4). The topic candidates added in step S4 also include the topic information 222a read from the hierarchical dictionary 222. Therefore, the requirement + topic candidate (auto + dictionary) 213 is output during processing in step S4. Details of the processing in step S4 will be given later with reference to Fig. 13 described.

[0053] Next, the display input unit 206 receives the requirement + the topic candidate (auto + dictionary) 213 and displays requirements and topic candidates in a new project to the user via the in Fig. 3. The request topic screen 30 is shown. When the user performs an action to view a different topic candidate on the request topic display section 34 of the request topic screen 30, the display input unit 206 reads topic information 222b from the hierarchical dictionary 222 and displays the topic information as topic candidates. The display input unit 206 then receives a completion instruction for the topic assignment operation from the user, the completion instruction being entered by the user clicking on the topic assignment completion section 33 (S5).

[0054] Upon receiving the completion instruction for the topic assignment process, the display input unit 206 saves the request 214 with the specified topics to the request topic DB 221 (S6), and processing is terminated. <Konfigurationsbeispiel für die Anforderungsthemen-DB und das hierarchische Wörterbuch>

[0055] Next, configuration examples for the requirement topic database 221 and the hierarchical dictionary 222 will be presented with reference to the Fig. 5 to 7 described.

[0056] Fig. Figure 5 is a diagram illustrating the configuration example for the requirements topic database 221, which contains requirements associated with existing projects. Requirements topic database 221 contains data with topics that are linked to existing requirements in a previous project (for example, project P1). Requirements topic database 221 includes fields for the data ID, project ID, requirements set, topic ID detail level 1, topic ID detail level 2, and topic ID detail level 3.

[0057] The "Data ID" field stores a data ID that can be identified for each request set. Data IDs D1 through D10 are provided in this field.

[0058] The "Project ID" field stores a project ID that allows for the identification of a previous project. The project ID stored in this field is P1.

[0059] The "Requirement Set" field stores a requirement set that contains a customer requirement from the previous project P1.

[0060] The field “Topic ID Detail Level 1” stores topics T1 and T2 at detail level 1.

[0061] The field “Topic ID Detail Level 2” stores the topics T1-1 and T2-1 at detail level 2.

[0062] The field “Topic ID Detail Level 3” stores the topic T1-1-1 at detail level 3.

[0063] Note that fields in the respective topic ID detail levels that show "None" indicate that no corresponding topic exists.

[0064] Fig. Figure 6 is a diagram illustrating an example of the configuration of hierarchical dictionary 222. In hierarchical dictionary 222, the topic and its subtopic are stored, along with a level of detail appropriate to the hierarchy. Hierarchical dictionary 222 contains fields for a topic ID, a level of detail, a topic, and an ID for parent topics.

[0065] The "Topic ID" field stores a topic ID that can be identified for each topic. For example, the topics T1, T1-1, T1-1-1, and T2 are stored in this field.

[0066] The "Level of Detail" field stores a level of detail defined for each topic. Fig. 6 represents detail levels 1 to 3, but detail levels of 4 or more can be set.

[0067] The "Topic" field stores the content of the topics. For example, "Torque Control" and "Accuracy of Torque Control" are stored as topics in this field.

[0068] The "Parent Topic ID" field stores a topic ID (referred to as "Parent Topic ID") of a parent topic that is one hierarchy level above the topic with a hierarchical structure. If the top-level topic is not the parent topic ID, it will be "None".

[0069] Fig. Figure 7 is a diagram illustrating the relationship between a hierarchical structure of topics and the levels of detail within those topics. Here, the description focuses on topics T1, T1-1, T1-1-1, and T1-2. The hierarchical structure of topics is defined by recording IDs for parent topics in the hierarchical dictionary 222.

[0070] Topic T1 at detail level 1 is the top-level topic. Therefore, the "ID parent topics" field in the... Fig. The hierarchical dictionary 6 shown contains 222 entries, but nothing is stored.

[0071] Topics T1-1 and T1-2 at detail level 2 correspond to topics that are one level below topic T1. Therefore, topic T1 is stored in the "ID for parent topics" field, which contains the topic IDs of hierarchical dictionary 222 T1-1 and T1-2.

[0072] The topic T1-1-1 at detail level 3 corresponds to a topic that is one level deeper than topic T1-1. Therefore, topic T1-1 is stored in the "Parent Topic ID" field, where the hierarchical dictionary topic ID is 222 T1-1-1.

[0073] Note that there can be multiple higher-level topics related to a given topic. In this case, multiple topic IDs are stored in the "ID for parent topics" field of hierarchical dictionary 222. <Verarbeiten der Lerndatenanpassungseinheit und Konfigurationsbeispiel für Lerndaten>

[0074] Next, the processing of the learning data adaptation unit 203 and a configuration example for learning data 203a will be described with reference to the Fig. 8 and Fig. 9 described.

[0075] The learning data fitting unit 203 extracts a sub-topic belonging to a hierarchy below the topic associated with the existing requirement (first requirement), based on the existing requirement (first requirement) obtained from the requirement topic database 221, the topic associated with the existing requirement (first requirement), and the hierarchical dictionary 222. Next, the learning data fitting unit (learning data fitting unit 203) outputs as training data (learning data 203a) a topic for which the number of existing requirements that have at least one associated with the topic extracted from the hierarchical dictionary 222 and the sub-topic is greater than or equal to a threshold.The training data 203a is used to train the classification model 204a, which assigns topic candidates to one or more new requirements described as the analysis target in a new document. Details of the processing in the training data fitting unit 203 are described below.

[0076] Fig. Figure 8 is a flowchart illustrating an example of processing in the learning data fitting unit 203. This processing is an example of the detailed processing in which it is presented. Fig. 4 shown step S1.

[0077] First, the learning data adaptation unit 203 reads the existing requirement 221a from the requirement topic DB 221 and calculates the number of data pieces in which respective topics are assigned requirements (S11).

[0078] Next, the learning data fitting unit 203 searches the hierarchical dictionary 222 and retrieves topic information 222c. Each learning data fitting unit 203 calculates the number of data pieces that have a subtopic of the topic and adds that number of data pieces to the number of data pieces to which each topic is added (S12).

[0079] Next, the learning data fitting unit 203 searches the hierarchical dictionary 222 and retrieves topic information 222c. Furthermore, the learning data fitting unit 203 extracts a topic that has a higher level of detail than the topic obtained in step S12 and whose number of requirements, including those for the subtopics, is greater than or equal to the threshold (S13). The level of detail for each topic is higher in the order of levels 1, 2, and 3.

[0080] Finally, the learning data adaptation unit 203 extracts from the requirement topic DB 221 the requirement that is associated with the topic extracted from the hierarchical dictionary 222, generates the learning data 203a of the extracted topic (S14) and finishes processing.

[0081] Fig. Figure 9 is a diagram showing the calculated number of requests for each topic ID. An example is described here, where the number of requests in step S1 of... Fig. The process shown in Figure 4 calculates the number of requirements that the topics contain, assuming that the topics are stored in the requirement topic database 221. The calculated number of data items for each topic includes a "Topic ID" field, a "Detail Level" field, a "Number of Requirements Associated with Topic ID" field, and a "Number of Requirements with Child Topics" field.

[0082] The "Topic ID" field stores a topic ID that can be identified for each topic. For example, the topics T1, T1-1, and T1-1-1 are stored in this field as topic IDs.

[0083] The "Level of Detail" field stores a level of detail defined for each topic. For example, this field stores levels of detail 1, 2, and 3.

[0084] The number of requirements to which topics are assigned is stored in the field "Number of requirements to which the topic IDs are assigned". The number of requirements refers to each data element that is identified by the data ID of the topic in Fig. The requirement topics DB 221 shown in the diagram are identified. The number of requirements to which the topic IDs are assigned corresponds to the number of data pieces identified in step S11 of Fig. 8 was calculated.

[0085] For example, since six topics T1 are stored in the "Topic ID Detail Level 1" field in the requirement topic database 221, in Fig. 9 in the field "Number of requirements to which the topic ID is assigned", "6" is stored. Similarly, since five topics T1-1 are stored in the field "Topic ID Detail Level 2" in the requirement topic DB 221, in Fig. 9 in the field “Number of requests that the topic ID is assigned”, “5” is stored.

[0086] The number of requirements that contain subtopics from the perspective of the parent topic is stored in the field "Number of requirements with subtopics". The number of requirements with subtopics corresponds to the number of data pieces entered in step S12 of Fig. 8 was calculated.

[0087] For example, six topics T1 are stored in the "Data ID" field of the requirement topic database 221 for D1 through D6. Topic T1-1, whose data ID is D7 and which is stored in the "Topic ID Detail Level 2" field, is a child topic of topic T1, and thus one topic T1-1 is stored. Since topic T1-1-1, whose data IDs are D8 and D9 and which is stored in the "Topic ID Detail Level 3" field, is the topic with the highest detail level and is a child topic of topic T1, two topics T1-1-1 are stored. The numerical value "9" as the total number of these requirements is stored in the "Number of Requirements with Child Topics" field.Similarly, the number of requirements assigned to the topic T1-1 is "5", but if the numerical value "3" is added as the number of topics to data D5, D8 and D9 with the sub-topic T1-1-1, the number of requirements with sub-topics is "8".

[0088] The training data adaptation unit 203 extracts the subordinate topic to which a higher level of detail is assigned than that of the other subordinate topics. In the present embodiment, the threshold for the number of training data pieces is "6". In this case, the training data adaptation unit 203 extracts the following during processing in step S1 of Fig. 4 as learning data 203a a topic and the existing requirement, which is in Fig. The topic T1-1 shown in section 9 is assigned to this topic to be extracted. Regarding this topic, the number of existing requirements to which a topic with a higher level of detail than the other topics extracted from the hierarchical dictionary 222 and at least one subtopic is assigned is greater than or equal to a threshold. Furthermore, processing to extract a topic whose number of requirements with a subtopic is greater than or equal to the threshold is carried out in step S13 in Fig. 8. The topic (for example, the topic "T1-1: Torque Control Accuracy") whose number of requirements with a subtopic is greater than or equal to the threshold is used for classification learning over a parent topic (for example, the topic "T1: Torque Control"). Therefore, even if the term "torque control" is not written in the new requirement R2, classification model 204a can perform a classification to identify the topic "T1: Torque Control" and the subtopic "T1-1: to be assigned to "torque control accuracy".

[0089] On the other hand, a detailed topic (for example, the subtopic “T1-1-1: The classification model 204a uses a requirement whose number of requirements with a sub-topic is below the threshold for classification learning on a parent topic whose number of requirements with a sub-topic is greater than or equal to the threshold. For example, even if the phrase "torque control accuracy" is not written in the new requirement R2, but "torque rise time" is, the classification model 204a can perform a classification to assign the topic "T1-1:" to requirement R2. to be assigned to "accuracy of torque control".

[0090] Fig. Figure 10 is a diagram showing an example where part of the requirements topic DB 221 is extracted, as well as an example of part of the learning data 203a.

[0091] A top side of Fig. Figure 10 shows an example that refers to the data sets D1, D2 and D3 from the in Fig. The 5 requirements topics shown are concentrated in DB 221. Based on this data set, processing in step S1 of Fig. 4 a data set of a requirement with the theme T1-1, which was extracted as the theme whose number of requirements exceeds the threshold, as learning data 203a.

[0092] A bottom side of Fig. Figure 10 shows a dataset extracted as training data 203a (an example of classification training data). A requirement containing a topic whose number of data pieces is greater than or equal to the threshold, where the topic is defined in step S13 of Fig. The data extracted from database 8 is extracted as classification training data. For example, data D2 and D3 are extracted from the requirement topic database 221, which is located at the top of... Fig. Figure 10 shows the data set of the requirement extracted with topic T1-1. Note that in the training data 203a, data D2 and D3 extracted from the requirement topic database 221 are replaced by data D1 and D2, respectively, because the data IDs are reassigned. Furthermore, the "Project ID," "Topic ID Detail Level 1," and "Topic ID Detail Level 3" fields, which are not required for training, are excluded from requirement topic database 221. <Beispiel für das Verarbeiten zum Klassifizieren von Themenkandidaten unter Verwendung der Detailebene>

[0093] Next, with reference to the Fig. 11 to 13 describe the processing in which the topic assignment unit 201 classifies a topic candidate using the level of detail and assigns a level of accuracy to the topic candidate.

[0094] Fig. Figure 11 is a diagram illustrating a configuration example for the analysis target requirement 211.

[0095] As in Fig. As shown in Figure 2, the display input unit 206 outputs the analysis target requirement 211 to the evaluation unit 205. The analysis target requirement 211 is data in which the Fig. The new project ID shown is P2, and the requirement IDs are R1 and R2. Analysis target requirement 211 contains a "Requirement ID" field and a "Requirement Set" field.

[0096] The "Request ID" field stores a request ID that can be identified for each request. For example, R1 and R2 are stored in this field as request IDs.

[0097] The "Requirement Set" field stores a requirement set. <Konfiguration: Beispiel von Anforderung + Themenkandidat (auto)>

[0098] Fig. 12 is a diagram illustrating a configuration example of requirement + topic candidate (auto) 212. As in Fig. Figure 2 shows that the requirement + topic candidate (auto) 212 represents a result of the assignment of topic candidates to the analysis target requirement 211 by the evaluation unit 205 using the classification model. The requirement + topic candidate (auto) 212 contains a field "Requirement ID", a field "Project ID", a field "Topic ID Candidate", a field "Level of Detail", and a field "Precision".

[0099] The "Request ID" field stores a request ID. For example, request R1 (example of the first request) of analysis target request 211 is stored in this field. Note that the representation and description of a record whose request ID is R2 are omitted.

[0100] The "Project ID" field stores a new project ID. For example, the new project P2, which is entered by input unit 31 for the new project ID in Fig. The value entered in step 3 is stored in the "Project ID" field.

[0101] The "Topic ID Candidate" field stores candidates for topic IDs that were automatically classified by the assessment unit 205 using classification model 204a. For example, the "Topic ID Candidate" field stores topics T1, T1-1, T1-12, and T3.

[0102] The "Level of Detail" field stores a level of detail for each topic. The level of detail for each topic is assigned with reference to the hierarchical dictionary 222. For example, regarding topic T1, level of detail 1 is stored in the "Level of Detail" field, and regarding topic T1-1, level of detail 2 is stored in the "Level of Detail" field.

[0103] The "Accuracy" field stores the accuracy calculated for each topic. Accuracy is indicated, for example, by any value from 0.0 to 1.0. If a topic has high accuracy, this indicates that the topic can be assigned to a requirement. Note that a topic with an accuracy of 0.1 or less is not a candidate to be assigned to the requirement, and therefore the topic is not added to the requirement + topic candidate (auto) 212.

[0104] In this way, the assessment unit 205 automatically assigns topic candidates to the requirement ID whose levels of detail can be classified by the classification model, and further assigns a precision to each topic whose level of detail has been classified. The assessment unit 205 does not assign topic candidates to the requirement ID whose precision is less than or equal to a threshold. For example, if the precision threshold is 0.3, the topic T3 of the topic ID candidate is not assigned to the requirement ID. <Beispiel für das Verarbeiten zum Ausgeben von Anforderung + Themenkandidat (auto + Wörterbuch)>

[0105] Next, an example of output processing of the requirement + topic candidate (auto + dictionary) 213 will be given with reference to Fig. 13 described. This processing is carried out by the topic assignment unit 201.

[0106] Fig. Figure 13 is a flowchart illustrating an example of output processing of the requirement + topic candidate (auto + dictionary) 213. This processing shows the details of the processing in step S4 in Fig. 4. The topic assignment unit 201 assigns to each topic candidate for a new requirement, to which topic candidates are assigned, the level of detail obtained from the hierarchical dictionary 222.

[0107] First, the topic assignment unit 201 waits for the input of requirement + topic candidate (auto) 212 from the evaluation unit 205 (S21). Upon receiving requirement + topic candidate (auto) 212, the topic assignment unit 201 starts a first loop processing and a second loop processing for each new requirement ID and topic candidate thereafter.

[0108] During the first loop processing, the topic mapping unit 201 performs a loop processing for each new requirement ID in a new project (S22). When the topic mapping unit 201 selects a new requirement ID, the processing continues to the second loop processing.

[0109] In the second loop processing, the topic assignment unit 201 performs a loop processing for each topic candidate assigned to the new requirement ID (each in Fig. 14 topic ID candidates shown and described later) by (S23). Upon extraction of a specific topic candidate, the topic mapping unit 201 searches the hierarchical dictionary 222 and extracts topics lower than the current topic candidates (S24). For example, if the current topic candidate is T1, the subordinate topics T1-1, T1-1-1, and T1-2 are extracted. The topic T1-1-1 is a topic being extracted for the first time at this time.

[0110] Next, the topic mapping unit 201 adds the subtopics extracted in step S24 to the topic candidate assigned to the current requirement (S25). For example, in a case where the current requirement is R1, the subtopics T1-1, T1-1-1, and T1-2 are assigned as topics associated with the current requirement.

[0111] After adding the subtopics, the topic mapping unit 201 returns to step S23 (S26) and selects the next topic candidates (S23). The processing is then repeated in steps S24 and S25 until there are no more topic candidates assigned to the new request ID. For example, if the next topic candidate is T3, the subtopic to be extracted is T3-1, and thus topic T3-1 is mapped to topic T3, which is the topic candidate.

[0112] If, during processing steps S23 to S26, there is no candidate to add to the topic, the topic mapping unit 201 returns to step S22 (S27) and selects the next new requirement ID (S22). The topic mapping unit 201 repeats the loop processing in steps S22 to S27 until there are no more new requirement IDs. If there are no new requirement IDs in the new project, processing continues to step S28.

[0113] In step S28, the topic mapping unit 201 outputs the request + the topic candidate (auto + dictionary) 213 to the display input unit 206 and ends the current processing. The display input unit 206 shows the topic IDs of the automatically mapped topics associated with the new request ID, on the [unclear text]. Fig. 3 requirements topic screen 30 shown. <Konfigurationsbeispiel für Anforderung + Themenkandidat (auto + Wörterbuch)>

[0114] Next, a configuration example for the requirement + topic candidate (auto + dictionary) 213, which is found in step S3 of Fig. 4 was created with reference to Fig. 14 described.

[0115] Fig. Figure 14 is a diagram illustrating the configuration examples of the requirement + topic candidate (auto) 212 and the requirement + topic candidate (auto + dictionary) 213.

[0116] The top side of Fig. Figure 14 illustrates the data configuration example for requirement + topic candidate (auto) 212. The data configuration example for requirement + topic candidate (auto) 212 was created with reference to Fig. 12 described.

[0117] A bottom side of Fig. Figure 14 shows an example of the data configuration of the request + topic candidate (auto) 213, which is mapped to topic ID candidates by the topic mapping unit 201. The field configuration of the request + topic candidate (auto) 213 is similar to the field configuration of the request + topic candidate (auto) 212.

[0118] The "Topic ID Candidate" field of the Requirement + Topic Candidate (auto) 213 stores topic ID candidates that were automatically classified by the Assessment Unit 205 using the classification model. For example, the "Topic ID Candidate" field stores topics T1-1-1 and T3-1, which were added by the Topic Mapping Unit 201, in addition to topics T1, T1-1, T1-12, and T3.

[0119] The "Detail Level" field stores a detail level for each topic. For the added topic T1-1-1, detail level "3" is stored, and for topic T3-1, detail level "2" is stored.

[0120] The "Accuracy" field stores the accuracy calculated for each topic. However, since topics T1-1-1 and T3-1 are topics extracted from hierarchical dictionary 222, this field stores "0" as the accuracy for both topics. Even with an accuracy of "0", a high-priority topic candidate can be assigned a topic with the highest possible level of detail. For example, in the topic candidate display section 37 of Fig. Three detailed topics with higher priority and the highest possible level of detail are displayed as topic candidates. Therefore, a user can determine the validity of topics with a high level of detail that are assigned to a new requirement.

[0121] Before processing in the topic assignment unit 201, the evaluation unit 205 assigns topic candidates up to "T1-1:" to requirement R1. Torque control accuracy." Therefore, the topic assignment unit 201 searches the hierarchical dictionary 222 and adds the topic "T1-1-1:" to the topic candidates. Torque rise time,” which lies under topic T1-1. Similarly, topic assignment unit 201 adds the topic “T3-1:” to the topic candidates. “Speed ​​control accuracy”, which is below topic T3, is added because the evaluation unit 205 of requirement R1 assigns topic candidates up to “T3: Speed ​​control”.

[0122] Furthermore, the topic mapping unit 201 sets the accuracy of the topic candidate extracted from the hierarchical dictionary 222 to "0" and determines the priority based on an average accuracy value of the combination of topics, the level of detail assigned to each topic, or the like. The request + the topic candidate (auto + dictionary) 213 is then output to the display input unit 206, and the topic candidates are presented to the user in order of their priority, as shown in Fig. 3 shown, presented. <Konfigurationsbeispiel für eine Anforderungsthemen-

[0123] DB to which a requirement for which a topic has been determined is added>

[0124] Fig. Figure 15 is a diagram showing a configuration example for the requirements topic database 221, which contains topics assigned to the requirements of the new project P2. The field configuration of requirements topic database 221 was created with reference to Fig. 5 described.

[0125] If the user accesses the topic assignment completion section 33 of the in Fig. When the user presses button 30 on the requirement topic screen 30 to complete the topic assignment, the topic selected on the requirement topic screen 30 is assigned to the requirement and stored in the requirement topic database 221. Therefore, in step S6 of Fig. 4 the requirement 214 (see Fig. 2), for which the topic was determined, to which in Fig. 5 requirements topics shown - DB 221 added.

[0126] Requirement 214, which was added to requirement topic DB 221 and for which the topic was assigned, is represented as data D11 and D12. The project ID for data D11 and D12 is P2. Furthermore, a requirement set is added to requirement topic DB 221. The topic ID for detail level 1 of the requirement set for data D11 is topic T1. The topic ID for detail level 1 of the requirement set for data D12 is topic T2, the topic ID for detail level 2 is topic T2-1, and the topic ID for detail level 3 is topic T2-1-1. <Anzeigebeispiel für Themenunterschied-Anzeigebildschirm>

[0127] Fig. Figure 16 is a diagram showing a display example of the topic difference display screen 40, which is displayed by the display input unit 206 on the display device 18. The display input unit 206 shows a difference between topics on the topic difference display screen 40. The topic difference display screen 40 can be displayed on the page shown in Fig. The topic difference display screen 40, shown in Figure 3, can be scrolled. The topic difference display screen 40 contains a project ID input section 41, a section 42 for starting the requirements comparison, a topic difference display section 43, and a section 44 for displaying detailed topic differences for each topic.

[0128] Project ID input section 41 contains input forms that allow a user to enter project IDs for comparing topics. For example, P2 is entered as a new project ID in the upper part of project ID input section 41, and P1 is entered as an existing project ID in the lower part. The user enters the project IDs in project ID input section 41 and clicks on section 42 to start the requirements comparison.

[0129] When section 42 is pressed to start the requirements comparison, an instruction 206a to start the project ID comparison is issued from the display input unit 206 to the topic difference comparison unit 202, as shown in Fig. Figure 2 shows the difference between topics, which is output by instruction 206a to start the project ID comparison from the topic difference comparison unit 202 to the display input unit 206, to identify a function that needs to be redeveloped in a new project and a function that is becoming redundant.

[0130] The topic difference comparison unit 202 uses not only the "new requirement" but also the "existing requirement" for requirement comparison. Therefore, the topic difference comparison unit 202 feeds a project ID 202a into the requirement topic database 221, reads the topics, and compares the differences between the topics of the new project and the existing project. The result of the comparison by the topic difference comparison unit 202 is classified, for example, based on each piece of information about the difference between topics and the difference between detailed topics for each topic, as to whether a topic exists "in both the existing and new project," "only in the existing project," or "only in the new project."

[0131] In the topic difference display section 43, one topic is shown that exists in both the existing and the new project, one topic exists only in the existing project, and one topic exists only in the new project. For example, the topics "T1: Torque Control" and "T2: Wake-up" are present in both the existing and the new project. The topic that exists only in the existing project is "T3: Speed ​​Control." The topic that exists only in the new project does not exist, as indicated by "(None)".

[0132] Section 44, which displays detailed topic differences for each topic, shows one detailed topic in both the existing and new projects, one detailed topic only in the existing project, and one detailed topic only in the new project for the topic at Detail Level 1. For example, in "T1: Torque Control," there is no detailed topic in either the existing or new project. However, for "T2: Wake-up," the detailed topic in both the existing and new projects is "T2-1: Trigger CAN."

[0133] Furthermore, what “T1: Regarding torque control, the detailed topics that are only present in the existing project, “T1-1: Torque control accuracy" and "T1-1-1: Torque rise time". On the other hand, there is in "T2: Regarding "Wake-up," there is no detailed topic that exists only in the existing project. Furthermore, regarding "T1: Torque Control," there is no detailed topic that exists only in the new project, but regarding "T2: Wake-up," the detailed topic that exists only in the new project is "T2-1-1: CAN Wake-up Time." <Beispiel für das Verarbeiten in der Themenunterschied-Vergleichseinheit>

[0134] The Fig. 17 and Fig. Figure 18 are flowcharts that show an example of the processing in the Topic Difference Comparison Unit 202. The Topic Difference Comparison Unit 202 compares the topic assigned to the first requirement (existing requirement) with the topic assigned to the second requirement (new requirement) for each hierarchy to which a corresponding topic belongs, and determines the difference between the topics.

[0135] First, the topic difference comparison unit 202 receives input of the project IDs to be compared and instruction 206a to start the project ID comparison from the user (S31). The project IDs to be compared are the project IDs of the existing project and the new project, which are based on the Fig. The data shown in the 16th issue of the topic difference display screen 40 was entered into the project ID input section 41. Furthermore, if the user presses section 42 to start the requirements comparison of the topic difference display screen 40, instruction 206a to start the project ID comparison is fed from the display input unit 206 into the topic difference comparison unit 202.

[0136] Next, the theme difference comparison unit 202 searches the requirement theme DB 221 for the project IDs of the new project and the existing project and reads the new requirement and the existing requirement of each project (S32).

[0137] Next, the topic difference comparison unit 202 performs loop processing for each existing requirement ID. During this loop processing, the processing in steps S33 to S38 is executed repeatedly (S33). First, the topic difference comparison unit 202 extracts a topic associated with the existing requirement (S34).

[0138] Next, the topic difference comparison unit 202 determines whether the extracted topic is included in a topic comparison list 230, which will be described later. Fig. 19 is shown, is available (p. 35). The topic comparison list 230 is a list that includes the one in Fig. The difference shown in section 215 between the new and existing requirements is represented. If the extracted topic is present in the topic comparison list 230 (YES in S35), the topic difference comparison unit 202 proceeds to step S37.

[0139] If, however, the extracted topic is not present in the topic comparison list 230 (NO in S35), the topic difference comparison unit 202 adds the topic to the topic comparison list 230 (S36). For example, the topic is added to an existing "Requirement Topic" field that is temporarily provided in the topic comparison list 230.

[0140] After the YES determination in step S35 or step S36, the topic difference comparison unit 202 sets a "Requirement Exists" flag for the extracted topic, indicating that the extracted topic is contained in the existing requirement (S37). Next, the topic difference comparison unit 202 determines whether loop processing has completed for all existing requirement IDs (S38). If loop processing has not completed for all existing requirement IDs, the topic difference comparison unit 202 selects the next existing requirement ID (S33) and repeats the loop processing. If, however, loop processing has completed for all existing requirement IDs, the topic difference comparison unit 202 proceeds to step S39 in... Fig. 18, which is connected to terminal A.

[0141] Next, the topic difference comparison unit 202 performs loop processing for each new request ID. This loop processing repeatedly executes the processing in steps S39 through S44 (S39 in Fig. 18). First, the theme difference comparison unit 202 extracts a theme that is assigned to the new requirement (S40).

[0142] Next, the topic difference comparison unit 202 determines whether the extracted topic is in the one to be described later. Fig. The extracted topic is present in the topic comparison list 230 shown in page 19 (S41). If the extracted topic is present in the topic comparison list 230 (YES in S41), the topic difference comparison unit 202 proceeds to step S43.

[0143] If, however, the extracted topic is not present in the topic comparison list 230 (NO in S41), the topic difference comparison unit 202 adds the topic to the topic comparison list 230 (S42). For example, the topic is added to the "Topic" field of the new requirement, which is temporarily provided in the topic comparison list 230.

[0144] After the YES determination in step S41 or step S42, the topic difference comparison unit 202 sets a "new requirement" flag for the extracted topic, indicating that the extracted topic is included in the new requirement (S43). Next, the topic difference comparison unit 202 determines whether loop processing is complete for all new requirement IDs (S44). If loop processing is not complete for all new requirement IDs, the topic difference comparison unit 202 selects the next new requirement ID (S39) and repeats the loop processing. If, however, loop processing is complete for all new requirement IDs, the topic difference comparison unit 202 proceeds to step S45.

[0145] The Theme Difference Comparison Unit 202 classifies the theme assigned to the first requirement (existing requirement) and the theme assigned to the second requirement (new requirement) into one of the following themes: the theme assigned to both the first requirement (existing requirement) and the second requirement (new requirement), the theme present only in the first requirement (existing requirement), or the theme present only in the second requirement (new requirement), and obtains a classification result as the difference between the themes. For example, based on information about the "Existing Requirement" and "New Requirement" flags, the Theme Difference Comparison Unit 202 classifies the themes into one of the following requirements: "In both requirements," "Only in the existing requirement," or "Only in the new requirement" (S45).Finally, the topic difference comparison unit 202 checks the level of detail of each topic with reference to the hierarchical dictionary 222, outputs the difference between the topics and the difference between the detailed topics for each topic (S46) and ends this processing. <Beispiel für Themenvergleichsliste>

[0146] Next, with reference to Fig. 19 describes an example of the topic comparison list 230.

[0147] Fig. Figure 19 is a diagram illustrating the processing to create the topic comparison list. Here, after (1) an example of the existing requirement and (2) an example of the new requirement have been described, the topic comparison list 230 is described, where the existing requirement and the new requirement are extracted through the topic difference comparison unit 202. (1) Example of an existing requirement extracted by the topic difference comparison unit 202

[0148] The topic difference comparison unit 202 extracts an existing requirement from the one in Fig. The 15 requirements topics shown are from DB 221. The field configuration of the extracted existing requirement is the same as that of requirements topic DB 221. For example, data with the existing project ID P1 is extracted from requirements topic DB 221. (2) Example of a new requirement extracted by the topic difference comparison unit 202

[0149] The topic difference comparison unit 202 extracts a new requirement from the one in Fig. The 15 requirements topics shown are from DB 221. The field configuration of the extracted new requirement is the same as that of requirements topic DB 221. For example, data with the new project ID P2 is extracted from requirements topic DB 221.

[0150] The bottom side of Fig. Figure 19 shows an example of the topic comparison list 230. The topic comparison list 230 contains a "Topic ID" field, a field indicating whether the topic should be included in the existing requirement, a field indicating whether the topic should be included in the new requirement, and a field for the classification result.

[0151] The "Topic ID" field stores the topic ID of each topic included in the new request and the existing request.

[0152] If a topic is included in the existing requirement, the field for whether the topic should be included in the existing requirement will store "YES", but if a topic is not included, the field for "Whether the topic should be included in the existing requirement" will store "NO".

[0153] If a topic is included in the new requirement, the field "Whether the topic should be included in the existing requirement" will be saved as "YES", but if a topic is not included, the field "Whether the topic should be included in the existing requirement" will be saved as "NO".

[0154] The "Classification Result" field stores a classification result obtained by the topic difference comparison unit classifying 202 topics based on the flag information.

[0155] Since, for example, the topic with topic ID T1 is included in both the existing requirement and the new requirement, the classification result is "in both requirements".

[0156] Since the topics with the topic IDs T1-1, T1-1-1 and T3 are only included in the existing requirement, the classification result is "only in existing requirement".

[0157] Since the topic with topic ID T2-1-1 is only included in the new request, the classification result is "only in new request".

[0158] The topic IDs classified in this way are used in Fig. Section 44 displays detailed topic differences for each topic. Therefore, a user can easily review the detailed topics in both an existing and a new project, the detailed topics only in the existing project, and the detailed topics only in the new project.

[0159] In the requirements analysis system 1, as described above, a topic with a defined level of detail is automatically assigned to a requirement, so that the topic assigned to the requirement is displayed on the requirement topic screen 30. Furthermore, the topic difference display screen 40 shows an analysis result obtained with respect to automatically topic-classified requirements by automatically analyzing the similarity and difference of topics assigned to existing requirements. Therefore, the user can easily perform recurring tasks such as adding their opinion and continuing the automatic analysis. Even if the granularity of the requirements varies depending on the customer, the requirements analysis system 1 extracts and classifies a topic from the requirement. Therefore, the user can easily grasp the topic contained in the requirement.

[0160] As a topic becomes more detailed, the meaning indicated by the topic becomes clearer. However, to address the problem of a decreasing number of documents (training data) with the same topic, requirements analysis system 1, according to one embodiment, creates a hierarchical dictionary 222 in which classification candidates are defined by hierarchizing them from schematic information to detailed information. The training data fitting unit 203 uses as training data 203a topics for which the number of requirements containing subtopics is greater than or equal to a threshold, the number of requirements being calculated based on the level of detail defined for each topic in the hierarchical dictionary 222.Therefore, in a case where there is a shortage of training data for detailed topics at a lower hierarchy level, where the detailed topics are defined in the hierarchical dictionary 222, the training data fitting unit 203 can automatically adjust the number of detailed topics so that the detailed topics are used for training on classification candidates of the topics at a higher hierarchy. Furthermore, the training data fitting unit 203 does not perform classification on topics with low classification reliability and a shortage of data. Therefore, the training data fitting unit 203 can generate the training data 203a suitable for creating the classification model 204a.

[0161] Since a suitable number of topics are also included in the training data 203a, the number of data pieces learned by the classification model training unit 204 also increases, and the accuracy of the classification model 204a is improved. The assessment unit 205 classifies topics included in the new requirement using the classification model 204a, which has learned the training data 203a in which the number of topics has been adjusted. For this reason, the accuracy with which the classification model 204a automatically classifies detailed topics is also improved.

[0162] The Requirements Topic screen 30 presents the user with subordinate, detailed topics of the automatically classified information. The topics assigned to the requirements are classified for each level of detail based on the hierarchical dictionary 222. The user can easily grasp the relationship between a given topic and another topic by viewing the Requirements Topic screen 30. As described above, the Requirements Analysis System 1 automatically assigns topics to a requirement of a new project and classifies the topics. When operating the system, the user simply needs to replace a requirement within a topic or replace a topic for a requirement.

[0163] The Topic Difference Display Screen 40 shows the difference between topics and the difference between detailed topics for each topic. For each requirement in an existing project and a new project, a topic is extracted from a document containing many requirements for each project, and the screen displays how the topics are represented in the requirements of the existing and new projects. Therefore, the user can easily grasp the classification of the topics included in the requirements of the new project and can process the new project accordingly. Furthermore, comparing the topics in the existing and new requirements makes it easier for the user to identify topics that are not included in the existing requirement and topics that are included but unnecessary. [Modifications]

[0164] Note that in the embodiment described above, the project IDs of the existing project and the new project are entered into the project ID input section 41 of the document. Fig. The topic difference display screen 16 shows that 40 can be entered, but a different project ID can also be entered. For example, requirements between several existing projects and a new project can be compared. Furthermore, assets that contain the content of several projects as variability can be compared.

[0165] The requirements analysis system 1 according to the present embodiment can use a classification model obtained from another requirements analysis system to enable the classification model to learn additionally. In this mode, the time required to adapt the classification model to a requirement of a project targeted by the requirements analysis system 1 according to the present embodiment can be significantly shorter than the time required to create a classification model from scratch.

[0166] Furthermore, the existing document and the new document can be used in one project, or different versions of a document can be used. In this case, the existing document can be an example of the first (old) version of the document, and the new document can be an example of the second (new) version of the document, which is newer than the first version.

[0167] Furthermore, the embodiment described above provides an example where the present invention is applied to projects and requirements in product development related to vehicle control systems, but the present invention is also applicable to other technical fields. For example, the present invention can be applied to system development in the areas of finance, communication, and information, where system development requires a large number of documents for each project.

[0168] The present invention is not limited to the embodiment described above, and it is self-evident that various other application examples and modifications can be made without deviating from the core of the invention described in the claims.

[0169] For example, in the embodiment described above, the system configuration has been described in detail and in a specific manner for easier understanding of the present invention, and the present invention is not necessarily limited to the invention that includes all the described configurations. Another configuration can be added to and deleted from a part of the configuration in the present embodiment, and that part of the configuration can be replaced by another configuration.

[0170] Furthermore, control and information lines deemed necessary for the description are specified, although not all control and information lines of a product are listed. In practice, it can be assumed that almost all configurations are interconnected. Reference symbol list 1 Requirements analysis system 10 client PCs 15 Requirements analysis tools 20 requirements analysis servers 26 Requirements Analysis Program 30 Request Topic Screen 40 Theme Difference Display Screen 201 Topic Assignment Unit 202 Topic Difference Comparison Unit 203 Learning Data Adjustment Unit 204 Classification Model Learning Unit 205 assessment units 206 Display-Input Unit 221 requirement topics database 222 Hierarchical Dictionary QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2018-169940 A

[0005]

Claims

[1] Requirements analysis system that includes: a requirements topic database that stores at least one initial requirement described in an initial document and a topic associated with that initial requirement; a hierarchical dictionary that stores several of the topics along with levels of detail that represent a hierarchical structure of the topics; a training data fitting unit that extracts subordinate topics belonging to a hierarchy below the topics associated with the at least one first requirement, based on the at least one first requirement obtained from the requirement topic database, the topics associated with the at least one first requirement, and the hierarchical dictionary, the at least one first requirement to which the topics are assigned, with respect to the topics of a number of the at least one first requirement to which at least one of the topics and the subordinate topics is assigned, greater than or equal to a threshold, as training data used to train a classification model that assigns candidates of the topics to at least a second requirement, described in a second document, as the analysis target, and in which a number of the topics are fitted; a learning unit that receives the learning data and creates the classification model; a topic candidate assignment unit that feeds the at least one second requirement into the classification model and assigns the candidates to the topics of the at least one second requirement; and a topic assignment unit that assigns the subordinate topics obtained from the hierarchical dictionary to the candidates of the topics of at least one second requirement to which the candidates of the topics are assigned. [2] Requirements analysis system according to claim 1, wherein the hierarchical dictionary stores the topics and the sub-topics together with the levels of detail assigned to the respective hierarchies, and the learning data fitting unit extracts the subtopics that have a higher level of detail than the other subtopics. [3] Requirements analysis system according to claim 2, further comprising a display input unit that displays the candidates of the topics on a requirements topic screen according to the levels of detail and in order of priority and, upon receiving a topic assignment operation to replace the candidates of the topics with other topics, outputs the at least one second requirement for which the candidates of the topics are replaced by the other topics to the topic candidate assignment unit. [4] Requirements analysis system according to claim 3, wherein the topic candidate assignment unit feeds the at least one second requirement, for which the candidates of the topics are replaced by the other topics, back into the classification model and assigns candidates of topics selected by the classification model to the at least one second requirement, and wherein the display-input unit, upon receiving a completion instruction of the topic assignment process, stores combinations of the at least one second requirement and the candidates of the topics assigned to the at least one second requirement in the requirement topic database. [5] Requirements analysis system according to claim 4, further comprising a theme difference comparison unit that compares the themes assigned to the at least one first requirement with the themes assigned to the at least one second requirement for the respective hierarchies to which the themes belong and obtains a difference between the themes. [6] Requirements analysis system according to claim 5, wherein the theme difference comparison unit classifies the themes assigned to the at least one first requirement and the themes assigned to the at least one second requirement into one of the themes assigned to both the at least one first requirement and the at least one second requirement, the themes contained only in the at least one first requirement, or the themes contained only in the at least one second requirement, in order to obtain a classification result as a difference between the themes. [7] Requirements analysis system according to claim 6, wherein the display input unit displays the difference between the topics on a topic difference display screen. [8] Requirements analysis system according to claim 6, wherein the first document is an existing document used in a previous project and the second document is a new document used in a new project. [9] Requirements analysis system according to claim 6, wherein the first document is a document of a first version and the second document is a document of a second version which is newer than the first version. [10] Requirements analysis procedure which features: (1) To cause a training data fitting unit contained in a requirements analysis system to extract subordinate topics belonging to a hierarchy below topics associated with at least one first requirement, based on the at least one first requirement obtained from a requirements topic database and described in a first document, the topics associated with the at least one first requirement, and a hierarchical dictionary storing several of the topics together with the levels of detail associated with the topics, and to output as training data in which a number of the topics are fitted and which are used to train a classification model,that assigns candidates to topics of at least one second requirement, which is described in a second document as an analysis objective; (2) Receiving the training data and creating the classification model; (3) Feeding the at least one second requirement into the classification model and assigning the candidates of the topics to the at least one second requirement; and (4) Assigning the subordinate topics of the candidates of the topics for each of the candidates of the topics to the at least one second requirement to which the candidates of the topics are assigned, the subordinate topics being obtained from the hierarchical dictionary.

Citation Information

Patent Citations

  • Learning device, learning method and learning program

    JP2018169940A