Requirements analysis system and requirements analysis method

Abstract

This request analysis system: uses an existing request, to which is assigned a topic for which the number of first requests having a topic and / or a subordinate topic assigned thereto is greater than or equal to a threshold, in the training of a classification model for assigning a topic candidate to one or more second requests described in a second document subject to analysis; outputs the existing request as learning data in which the number of topics is adjusted; creates a classification model by using the learning data as input; inputs a second request to the classification model, and assigns a topic candidate to the second request; and for each topic candidate, assigns, to the second request to which the topic candidate is assigned, a topic subordinate to the topic candidate acquired from a hierarchical dictionary.

Description

[[Technical Field]]

[0001] The present invention relates to a requirement analysis system and a requirement analysis method. [[Background Art]]

[0002] In product development, customers put forward various requirements, so product developers need to analyze the requirements from customers and grasp what functions are required. For example, developers have performed customer requirement analysis, such as considering which requirement a product function, as a development unit, should be classified into, or assigning features mentioned in requirements to grasp differences from existing products. However, since customer requirements are described in various documents and documents with a large number of pages, automation of analysis work applying machine learning has been progressing in order to perform customer requirement analysis in a shorter time and more accurately than before.

[0003] In order to automatically determine and classify functions related to customer requirements and features of requirements, it is necessary to train a classification algorithm in machine learning. To improve the accuracy of automatic classification, it is necessary to create training data in which correct classification result information is assigned to requirements. The classification result information is information representing the result of classifying functions or features (referred to as "topics" in the following description) for requirements made in the past.

[0004] Patent Document 1 describes that "when classifying a plurality of documents into clusters using words included in the documents, the learning device assigns a label to each word used for cluster classification. The learning device classifies a plurality of documents into clusters using the labels assigned to the respective words. Further, when a cluster classified using a first word is similar to a cluster classified using a second word, the learning device assigns a label common to the label assigned to the first word to the second word." [[Prior Art Documents]] [[Patent Documents]]

[0005] [Patent Document 1] Japanese Patent Publication No. 2018-169940 [Overview of the project] [Problems that the invention aims to solve]

[0006] By the way, if there isn't enough training data, the accuracy of automatic classification decreases, causing the classification algorithm to make incorrect classification decisions. In this case, the topic classification result by machine learning is incorrect, and customer requests cannot be classified correctly. Also, the more detailed a topic is, the clearer its meaning becomes, but the number of documents with the same topic, i.e., the number of customer requests, decreases. For this reason, a mechanism is needed in which the content classified by the user (for example, a designer) as part of their daily work is used as training data for the machine learning device and fed back into automatic classification, but traditionally, learning has not been carried out from this perspective.

[0007] Furthermore, the topics of requirements differ depending on the customer, and even within the same customer, depending on the development project. For example, customer A defines requirements in detail, while customer B only defines them at a general level. Because the level of detail in requirements differs from customer to customer, simply comparing requirements unit by unit makes it difficult to identify topics to reuse or create based on their consistency with existing requirements. In addition, while Patent Document 1 describes integrating multiple labeled words into a single cluster, such integration alone makes automatic topic classification difficult.

[0008] This invention was made in view of the above circumstances, and aims to adjust the training data used to train a classification model that classifies requests, assign appropriate topics to requests, and classify the requests. [Means for solving the problem]

[0009] The requirements analysis system according to the present invention comprises: a requirements topic database that stores one or more first requirements described in a first document and topics assigned to the first requirements; a hierarchical dictionary that stores multiple topics along with a level of detail representing the hierarchical structure of the topics; a learning data adjustment unit that extracts subordinate topics belonging to a lower hierarchy than the topics assigned to the first requirements based on the first requirements and topics assigned to the first requirements obtained from the requirements topic database and the hierarchical dictionary, and outputs first requirements to which at least one of the topics and subordinate topics assigned is equal to or greater than a threshold, as learning data in which the number of topics is adjusted for training a classification model that assigns topic candidates to one or more second requirements described in a second document to be analyzed; a learning unit that creates a classification model using the learning data as input; a topic candidate assignment unit that inputs the second requirements to the classification model and assigns topic candidates to the second requirements; and a topic assignment unit that assigns subordinate topics to the topic candidates obtained from the hierarchical dictionary to each topic candidate for the second requirements to which topic candidates have been assigned. [Effects of the Invention]

[0010] According to the present invention, a classification model created by adjusting the training data used to train the classification model can be used to assign subtopics to candidate topics assigned to a second request, thereby classifying the request. [Brief explanation of the drawing]

[0011] [Figure 1] Block diagram showing an example of the hardware configuration of a requirements analysis system according to one embodiment of the present invention. [Figure 2] Block diagram showing an example of the functional configuration of a requirements analysis system according to one embodiment of the present invention. [Figure 3] This figure shows an example configuration of a request topic screen displayed on a display device by a display input unit according to one embodiment of the present invention. [Figure 4] This flowchart shows an example of the processing of a requirements analysis program related to one embodiment of the present invention. [Figure 5] This figure shows an example configuration of a request topic database, which includes topics assigned to requests of existing projects related to one embodiment of the present invention. [Figure 6] This figure shows an example of the configuration of a hierarchical dictionary according to one embodiment of the present invention. [Figure 7] This figure shows the relationship between the hierarchical structure and level of detail of topics related to one embodiment of the present invention. [Figure 8] This flowchart shows an example of the processing of the learning data adjustment unit according to one embodiment of the present invention. [Figure 9] This diagram shows the calculation results for the number of requests per topic ID related to one embodiment of the present invention. [Figure 10] This figure shows an example of extracting a portion of the request topic database related to one embodiment of the present invention, and an example of a portion of the training data. [Figure 11] This figure shows an example of the configuration of the requirements to be analyzed related to one embodiment of the present invention. [Figure 12] This figure shows an example configuration of requirements + topic candidates (automatic) related to one embodiment of the present invention. [Figure 13] This flowchart shows an example of the output processing of requests + topic candidates (automatic + dictionary) according to one embodiment of the present invention. [Figure 14] This figure shows an example configuration of a request + topic candidate (automatic) and a request + topic candidate (automatic + dictionary) according to one embodiment of the present invention. [Figure 15] This figure shows an example configuration of a request topic database, which includes topics assigned to requests for new projects related to one embodiment of the present invention. [Figure 16] This figure shows an example of a topic difference display screen shown on a display device by a display input unit according to one embodiment of the present invention. [Figure 17] This flowchart shows an example of the processing of the topic difference comparison unit according to one embodiment of the present invention (first half). [Figure 18] This flowchart shows an example of the processing of the topic difference comparison unit according to one embodiment of the present invention (second half). [Figure 19] It is a diagram illustrating a process of generating a topic comparison list according to an embodiment of the present invention. MODE FOR CARRYING OUT THE INVENTION

[0012] Hereinafter, embodiments for carrying out the present invention will be described with reference to the accompanying drawings. In the present specification and the accompanying drawings, components having substantially the same function or configuration are denoted by the same reference numerals, and redundant descriptions thereof are omitted.

[0013] [One Embodiment] <Example Hardware Configuration of Requirement Analysis System> First, an example hardware configuration of the requirement analysis system 1 will be described with reference to FIG. 1. FIG. 1 is a block diagram showing an example hardware configuration of the requirement analysis system 1 according to an embodiment of the present invention.

[0014] The requirement analysis system 1 includes a client PC (Personal Computer) 10 and a requirement analysis server 20. The client PC 10 and the requirement analysis server 20 form a server-client system configuration. For example, the client PC 10 can access the requirement analysis server 20 constructed on-premises via a communication line such as a LAN (Local Area Network). However, the requirement analysis server 20 may be configured as a virtual machine on a cloud. In this case, the client PC 10 can access the requirement analysis server 20 via an external network such as the Internet. Further, the client PC 10 may be configured to have only an input device 17 and a display device 18, and can check the classification result of requirement analysis performed by the requirement analysis server 20 via a web browser.

[0015] First, an example internal configuration of the client PC 10 will be described. The client PC 10 is equipped with a CPU (Random Access Memory) 11, RAM (Random Access Memory) 12, storage 13, ROM (Read Only Memory) 14, a network interface 16, an input device 17, and a display device 18.

[0016] The CPU 11 reads the program code for the software that implements each function according to this embodiment (for example, the requirements analysis tool 15) from the ROM 14, loads it into the RAM 12, and executes it. Variables and parameters that occur during the calculation process of the CPU 11 are temporarily written to the RAM 12, and these variables and parameters are read out by the CPU 11 as appropriate. The requirements analysis tool 15 is a software program that can be executed on the client PC 10 and can instruct the requirements analysis server 20 to perform requirements analysis. The requirements analysis tool 15 also provides a user interface that the user can input or view on the screen.

[0017] Storage 13 is a non-volatile storage medium that stores the OS (Operating System), various parameters, and programs necessary for the client PC 10 to function. Examples of storage 13 include HDD (Hard Disk Drive), SSD (Solid State Drive), or non-volatile memory. Storage 13 and ROM 14 store programs and data necessary for the CPU 11 to operate, and are used as an example of a computer-readable, non-transient storage medium containing programs executed by the client PC 10.

[0018] The network interface 16 can, for example, use a NIC (Network Interface Card), and various types of data can be sent and received with the request analysis server 20 via a LAN, dedicated line, or internet communication line connected to the terminals of the NIC.

[0019] The input device 17 can be, for example, a keyboard or mouse, allowing the user to perform predetermined operations and give instructions. The display device 18 is, for example, a liquid crystal display monitor, which displays the results of processing performed on the client PC 10 to the user.

[0020] Next, we will describe an example of the internal configuration of the requirements analysis server 20. The requirements analysis server 20 includes a server CPU 21, server RAM 22, server storage 23, server network interface 24, and server ROM 25.

[0021] The server CPU 21 reads the program code for the software that implements each function according to this embodiment (for example, the requirements analysis program 26) from the server ROM 25, loads it into the server RAM 22, and executes it. Variables and parameters that occur during the calculation process of the server CPU 21 are temporarily written to the server RAM 22, and these variables and parameters are read out by the server CPU 21 as appropriate. The requirements analysis program 26 is a software program that can be executed on the requirements analysis server 20 and provides various functions according to this embodiment shown in Figure 2, which will be described later. For example, both existing and new projects have many documents, and multiple requirements are defined in each document. Therefore, the requirements analysis program 26 counts the number of requirements regardless of the number of pages in the document, and extracts topics from the counted requirements. Topics are, for example, keywords, annotations, notes, etc. that are attached to the document in which the requirements are described.

[0022] The server storage 23 is a non-volatile storage medium that stores the OS, various parameters, and programs necessary for the request analysis server 20 to function. For example, an HDD, SSD, or non-volatile memory can be used as the server storage 23. The server storage 23 and server ROM 25 store programs and data necessary for the server CPU 21 to operate, and are used as an example of a non-transient storage medium readable by a computer that stores programs executed by the request analysis server 20.

[0023] For example, a network interface (NIC) can be used for the server network interface 24, and various types of data can be sent and received with the client PC 10 via a LAN, dedicated line, or internet communication line connected to the terminals of the NIC.

[0024] Although Figure 1 shows an example where the requirements analysis system 1 is composed of a client PC 10 and a requirements analysis server 20, the functions of the requirements analysis server 20 may be integrated into a single client PC 10. In this case, the client PC 10 is configured as a standalone unit, and the requirements analysis tool 15 performs the functions of the requirements analysis program 26.

[0025] <Example of a requirements analysis system's functional configuration> Next, we will explain an example of the functional configuration of the requirements analysis system 1 with reference to Figure 2. Figure 2 is a block diagram showing an example of the functional configuration of the requirements analysis system 1. The contents of each functional block shown in Figure 2 will be explained while referring to the drawings from Figure 3 onwards. Each functional block shown in Figure 2 is configured in the requirements analysis program 26 shown in Figure 1, and each database is configured in the server storage 23 shown in Figure 1. In addition, the various data created by each functional block are temporarily stored in the server RAM 22 shown in Figure 1 and read out as needed.

[0026] The requirements analysis system 1 comprises a topic assignment unit 201, a topic difference comparison unit 202, a learning data adjustment unit 203, a classification model learning unit 204, an evaluation unit 205, a display input unit 206, a requirements topic database (DB:Data Base) 221, and a hierarchical dictionary 222. Between each functional unit, the following are generated: the requirements to be analyzed 211, the requirements + topic candidates (automatic) 212, the requirements + topic candidates (automatic + dictionary) 213, the requirements with determined topics 214, and the differences between new and existing requirements 215.

[0027] Existing requirements are customer requirements that were implemented in past projects, and these requirements are assigned topics of varying levels of detail based on the design results. Therefore, the requirements analysis system 1 can use existing requirements as training data for its classification model. On the other hand, new requirements are customer requirements to be implemented in new projects and are not assigned topics. Therefore, new requirements are the targets for which the requirements analysis system 1 automatically classifies topics using its classification model, and are also called analysis targets.

[0028] The display input unit 206 displays a user-inputtable screen on the client PC 10. To this end, the display input unit 206 creates screen data that constitutes the screen and sends it to the client PC 10 via the server network interface 24. When the requirements analysis tool 15 on the client PC 10 receives the screen data via the network interface 16, it displays the requirements topic screen 30 (see Figure 3) and the topic difference display screen 40 (see Figure 16), described later, on the display device 18 based on this screen data. The display input unit 206 also passes the instructions entered through the screen to the requirements analysis tool 15. The requirements analysis tool 15 outputs the user's instructions to the requirements analysis server 20 via the network interface 16. The requirements analysis server 20 outputs the instructions received via the server network interface 24 to the display input unit 206, and the display input unit 206 outputs instructions to the necessary function blocks according to the instructions.

[0029] The display input unit (display input unit 206) displays topic candidates on the request topic screen 30 in order of detail and priority. When a topic assignment operation is input to replace a topic candidate with another topic, it outputs a second request (new request: for example, the analysis target request 211) in which the topic candidate has been replaced with another topic to the evaluation unit 205.

[0030] Figure 3 shows an example of the configuration of the request topic screen 30 displayed on the display device 18 by the display input unit 206. The request topic screen 30 includes a new project ID input unit 31, an analysis target request reading unit 32, a topic assignment completion unit 33, and a request topic display unit 34.

[0031] When the user determines a new project ID, they write the new project ID to the new project ID input unit 31. The new project ID is, for example, P2, and the new project includes the new request described above. Next, when the user clicks the request to be analyzed loading unit 32, the request analysis program 26 shown in Figure 1 reads the request file from the request topic DB 221. The request file has the same field structure as the request topic DB 221. The request topic DB 221 is an example of a database that stores one or more existing requests described in an existing document (first document), and topics assigned to the existing requests (first requests).

[0032] As described above, the existing document is an example of a first document used in past project P1 (see Figure 5), and the new document is an example of a second document used in the new project P2. Furthermore, the "request to be analyzed" in the request to be analyzed reading unit 32 corresponds to the new request mentioned above, and represents an operation for the user to consider what topics to assign to the new customer request.

[0033] The request topic display unit 34 has fields for the request ID, request statement, multiple topic IDs, and automatic classification candidates of the request file read from the request topic DB 221. Topics are managed in a hierarchical structure where topics with higher levels of content are assigned a level of detail of 1, and topics with the next highest level are assigned a level of detail of 2. Topic ID 34-1 stores the topic ID of a topic with a level of detail of 1. Topic ID 34-2 stores the topic ID of a topic with a level of detail of 2, and topic ID 34-3 stores the topic ID of a topic with a level of detail of 3. Topics with a level of detail of 2 or higher are also called "detailed topics".

[0034] For example, the first record from the top is a record containing a request for an inverter system, with request ID R1, request statement "Inverter system shall control e-Motor torque.", topic ID 34-1 is topic T1 with a level of detail of 1, topic ID 34-2 is topics T1-1, T1-2 with a level of detail of 2, topic ID 34-3 is topics T1-1-1, ... with a level of detail of 3. In the following explanation, "request statement" may be referred to as "request". Also, request R1 in existing project P1 is an existing request (an example of a first request).

[0035] Users can select a topic at each level of detail from a dropdown list provided in the topic ID field. For example, a user can select one of the following from the dropdown list for the topic "T1" at level 1: "T1: Torque Control", "T2: Wake Up", or "T3: Rotational Speed ​​Control". Users can also select a detailed topic from the dropdown list for topics at levels 2 and 3. The detailed topics at each level of detail correspond to the content of the hierarchical dictionary 222 shown in Figure 2 and Figure 6 described later.

[0036] The field for automatically classified candidates is provided with a display instruction unit 36 ​​that, when clicked by the user, displays a topic candidate display unit 37 overlaid on the request topic screen 30. When the user presses the display instruction unit 36, the topic candidates that the request analysis system 1 has previously analyzed and classified are displayed in the topic candidate display unit 37 in order of priority. The priority is determined by the accuracy of the automatic classification, the number of topic candidates classified by the hierarchical dictionary 222, etc. The hierarchical dictionary (hierarchical dictionary 222) is an example of a database that stores multiple topics along with a level of detail that represents the hierarchical structure of the topics, and the hierarchy to which a topic belongs is defined by the hierarchical dictionary 222.

[0037] The topic candidate display unit 37 displays the topic ID, but it may also display the content of the topic associated with the topic ID (see Figure 6, described later). When a user selects a topic from the topic candidates displayed in the requested topic display unit 34, the selected topic is automatically reflected in the row where the user pressed the display instruction unit 36. For example, in a record for a topic ID with request ID R2, the dropdown list displays "T1: Torque Control", "T2: Wake Up", and "T3: Rotation Speed ​​Control" as automatic classification results. Request R2 is called a new request for new project P2 (an example of a second request). When the user selects "T2: Wake Up", the detailed topics below topic T2 (topics T2-1, T2-1-1) are displayed as topic candidates. The level to which topics can be automatically classified depends on the calculated accuracy value of the automatic classification and the number of documents used for learning.

[0038] The evaluation unit 205 is an example of a topic candidate assignment unit that takes a second request (new request) as input to a classification model (classification model 204a) and assigns topic candidates to the second request (new request). Furthermore, the evaluation unit 205 inputs the new request, in which the topic candidates have been replaced with other topics, back into the classification model 204a, and assigns the topic candidates selected by the classification model 204a to the new request. The classification model 204a has the function of classifying and assigning topic candidates to the new request based on keywords etc. described in the new request when a new request is input. The new request to which topic candidates have been assigned is displayed again on the request topic screen 30.

[0039] Once the user has finished selecting a topic for a request, they click the topic assignment completion unit 33. When the user clicks the topic assignment completion unit 33, the display input unit 206 receives an instruction to complete the topic assignment operation. Upon receiving the instruction to complete the topic assignment operation, the display input unit 206 saves the new request and the candidate topic combinations assigned to the new request to the request topic DB 221. With the request topic screen 30 configured in this way, it becomes easier for the user to classify topics and for the request analysis program 26 to repeatedly learn and automatically classify topics for efficient request analysis.

[0040] Traditionally, it was necessary to be able to learn from user classifications made as part of daily work and feed that data back into automatic classification. However, there was a constraint that adding a task solely for the purpose of assigning topics would be inappropriate, as it would increase the workload of analyzing requirements for new projects if users were to assign topics themselves. To address this challenge, the requirements analysis system 1 presents the user with corresponding lower-level detailed topic candidates via the requirements topic screen 30, using a hierarchical dictionary 222, based on the results of automatic classification of higher-level topics. As a result, users can easily perform the task of classifying requirements by topic and then assigning even more detailed topics to those requirements.

[0041] <Example of processing in a requirements analysis program> Next, an example of the processing of the requirements analysis program 26 will be explained with reference to Figures 2 and 4. Figure 4 is a flowchart illustrating an example of the processing of the requirements analysis program 26. This flowchart explains the requirements analysis method performed by the requirements analysis system 1.

[0042] First, when the learning data adjustment unit 203 detects that the request topic DB 221 has been updated, it starts learning and generates learning data 203a (S1). This learning data 203a is output to the classification model learning unit 204. The trigger for starting learning may also be an instruction explicitly entered by the user. Details of the process in step S1 will be described later with reference to Figure 8.

[0043] Next, the learning unit (classification model learning unit 204) takes the learning data (learning data 203a) as input and learns a classification model (classification model 204a) (S2). Note that the learning of the classification model learning unit 204 by the classification model learning unit 204 is synonymous with the creation of the classification model 204a. This classification model 204a is output to the evaluation unit 205.

[0044] The training data 203a may be recorded in the request topic DB 221. In this case, the classification model training unit 204 may read the training data 203a from the request topic DB 221 and train the classification model 204a.

[0045] Next, the evaluation unit 205 inputs a new request to the classification model 204a, which then outputs a new request with topic candidates assigned to it. For example, when the evaluation unit 205 receives input of an analysis target request 211 generated by clicking the analysis target request reading unit 32 on the request topic screen 30 shown in Figure 3, it starts analyzing the analysis target request 211 using the classification model 204a. Subsequently, the evaluation unit 205 automatically assigns topic candidates to the analysis target request 211 using the classification model 204a (S3). This process in which the classification model 204a automatically assigns topic candidates to the analysis target request 211 is called "evaluation". Note that in Figure 12, which will be described later, topic candidates are represented by topic ID candidates.

[0046] The analysis target request 211, to which topic candidates have been automatically assigned, is output to the topic assignment unit 201 as request + topic candidate (automatic) 212. The topic candidate (automatic) is a topic candidate that has been automatically assigned by the classification model 204a to the analysis target request 211.

[0047] Next, the topic assignment unit 201 assigns subordinate topics (detailed topics) to each topic candidate obtained from the hierarchical dictionary 222 to the second request (new request) to which topic candidates have been assigned. For example, the topic assignment unit 201 determines the detailed topic for the request + topic candidate (automatic) 212 based on the topic information 222a read from the hierarchical dictionary 222. The topic assignment unit 201 also adds topic candidates and topic information to the request + topic candidate (automatic) 212 (S4). The topic candidates added in step S4 also include the topic information 222a read from the hierarchical dictionary 222. As a result of the processing in step S4, the request + topic candidate (automatic + dictionary) 213 is output. Details of the processing in step S4 will be described later with reference to Figure 13.

[0048] Next, the display input unit 206 takes the request + topic candidate (automatic + dictionary) 213 as input and displays the request and topic candidate for the new project to the user through the request topic screen 30 shown in Figure 3. When the user performs an operation to display other topic candidates from the request topic display unit 34 on the request topic screen 30, the display input unit 206 reads topic information 222b from the hierarchical dictionary 222 and displays it as a topic candidate. After that, the display input unit 206 receives the user's instruction to complete the topic assignment operation, which is entered by the user clicking the topic assignment completion unit 33 (S5).

[0049] Upon receiving the instruction to complete the topic assignment operation, the display input unit 206 stores the request 214 with the determined topic in the request topic DB 221 (S6), and terminates this process.

[0050] <Example configuration of a request topic database and hierarchical dictionary> Next, an example configuration of the request topic DB221 and the hierarchical dictionary 222 will be explained with reference to Figures 5 to 7.

[0051] Figure 5 shows an example of the configuration of the Request Topic DB221, which contains topics assigned to requests of existing projects. The Request Topic DB221 stores data including topics assigned to existing requests of past projects (for example, Project P1). The Request Topic DB221 consists of the following fields: Data ID, Project ID, Request Statement, Topic ID Detail Level 1, Topic ID Detail Level 2, and Topic ID Detail Level 3.

[0052] The Data ID field stores a unique Data ID for each request statement. Data IDs are assigned as D1 through D10. The Project ID field stores a Project ID that identifies past projects. In this case, P1 is stored as the Project ID. The request statement field stores request statements, including customer requests from past projects P1.

[0053] The Topic ID Detail Level 1 field stores topics T1 and T2 with a detail level of 1. The Topic ID Detail Level 2 field stores topics T1-1 and T2-1 with a detail level of 2. The Topic ID detail level 3 field stores topic T1-1-1, which has a detail level of 3. Note that if "None" is entered in any field of the Topic ID detail level, it indicates that there is no corresponding topic.

[0054] Figure 6 shows an example of the structure of a hierarchical dictionary 222. The hierarchical dictionary (hierarchical dictionary 222) stores topics and subtopics, along with the level of detail assigned to each level. This hierarchical dictionary 222 consists of the following fields: topic ID, level of detail, topic, and parent topic ID.

[0055] The Topic ID field stores a unique topic ID for each topic. For example, it may store topics such as T1, T1-1, T1-1-1, T2, etc. The detail level field stores the detail level set for each topic. In Figure 6, the detail level is set to 1 through 3, but a level of detail of 4 or higher may also be set. Topic fields store the content of topics. For example, "torque control" and "torque control accuracy" are stored as topics. The "Top Topic ID" field stores the topic ID of the topic that is one level above the current topic in the hierarchical structure (referred to as the "Top Topic ID"). The top-level topic does not have a Top Topic ID stored in it; instead, "None" is stored.

[0056] Figure 7 shows the relationship between the hierarchical structure of topics and their level of detail. Here, we will focus on topics T1, T1-1, T1-1-1, and T1-2. The hierarchical structure of topics is defined by recording the parent topic IDs in the hierarchical dictionary 222.

[0057] Topic T1, with a level of detail of 1, is the top-level topic. Therefore, the top-level topic ID field in the hierarchical dictionary 222 shown in Figure 6 contains nothing. Topics T1-1 and T1-2, with a level of detail of 2, are one level below topic T1. Therefore, in the hierarchical dictionary 222, the parent topic ID field for topic IDs T1-1 and T1-2 will both store topic T1. Topic T1-1-1, with a level of detail of 3, is one level below topic T1-1. Therefore, in the hierarchical dictionary 222, the parent topic ID field of topic T1-1-1 will store topic T1-1.

[0058] Note that a given topic may have multiple parent topics. In this case, multiple topic IDs are stored in the parent topic ID field of the hierarchical dictionary 222.

[0059] <Processing of the training data adjustment unit and an example of the training data structure> Next, the processing of the learning data adjustment unit 203 and an example of the configuration of the learning data 203a will be explained with reference to Figures 8 and 9.

[0060] The learning data adjustment unit 203 extracts sub-topics belonging to a lower hierarchy than the topics assigned to the existing requests (first requests) based on the existing requests (first requests) obtained from the request topic DB 221, the topics assigned to the existing requests (first requests), and the hierarchical dictionary 222. Next, the learning data adjustment unit (learning data adjustment unit 203) outputs topics from the topics and sub-topics extracted from the hierarchical dictionary 222 to which at least one existing request is assigned a threshold or greater, as learning data (learning data 203a) with the number of topics adjusted. This learning data 203a is used to train the classification model 204a, which assigns topic candidates to one or more new requests described in the new document to be analyzed. The details of the processing of the learning data adjustment unit 203 are described below.

[0061] Figure 8 is a flowchart showing an example of the processing in the learning data adjustment unit 203. This process is a detailed example of step S1 shown in Figure 4.

[0062] First, the learning data adjustment unit 203 reads existing requests 221a from the request topic DB 221 and calculates the number of data to which each topic is assigned to each request (S11).

[0063] Next, the learning data adjustment unit 203 searches the hierarchical dictionary 222 and obtains topic information 222c. The learning data adjustment unit 203 also calculates the number of data points that have topics below a given topic and adds this to the total number of data points to which each topic is assigned (S12).

[0064] Next, the learning data adjustment unit 203 searches the hierarchical dictionary 222 and obtains topic information 222c. The learning data adjustment unit 203 also extracts topics that have a higher level of detail than the topics obtained in step S12 and whose number of requests, including lower-level topics, is above a threshold (S13). The level of detail of the topics increases in the order of 1, 2, and 3.

[0065] Finally, the learning data adjustment unit 203 extracts requests corresponding to the topics extracted from the hierarchical dictionary 222 from the request topic DB 221, generates learning data 203a for the extracted topics (S14), and terminates this process.

[0066] Figure 9 shows the calculation results for the number of requests per topic ID. Here, we explain an example of calculating the number of requests including topics, based on the process shown in step S1 of Figure 4, assuming topics stored in the request topic DB221. The calculation results for the number of data per topic consist of the following fields: topic ID, level of detail, number of requests assigned to topic ID, and number of requests including subordinate topics.

[0067] The Topic ID field stores a unique topic ID for each topic. For example, topics T1, T1-1, and T1-1-1 are stored as topic IDs. The detail field stores the detail level set for each topic. For example, detail levels 1, 2, and 3 are stored there.

[0068] The request count field, assigned a topic ID, stores the number of requests assigned to each topic. The request count is each data item identified by the data ID in the request topic DB221 shown in Figure 5. The request count assigned a topic ID corresponds to the number of data items calculated in step S11 in Figure 8.

[0069] For example, since topic T1 is stored 6 times in the topic ID detail level 1 field of the requested topic DB221, 6 is stored in the requested number field with the assigned topic ID in Figure 9. Similarly, since topic T1-1 is stored 5 times in the topic ID detail level 2 field of the requested topic DB221, 5 is stored in the requested number field with the assigned topic ID in Figure 9.

[0070] The "Number of Requests Including Subtopics" field stores the total number of requests, including subtopics, relative to the top-level topic. This number of requests, including subtopics, corresponds to the number of data points calculated in step S12 of Figure 8.

[0071] For example, topic T1 is stored 6 times in the data ID field of the requested topic DB221, corresponding to D1 through D6. Additionally, topic T1-1, which has data ID D7 and is stored in the topic ID detail level 2 field, is a subordinate topic to topic T1 and is stored 1 time. Furthermore, topic T1-1-1, which has data IDs D8 and D9 and is stored in the topic ID detail level 3 field, is the topic with the highest detail level and is also a subordinate topic to topic T1, so it is stored 2 times. The sum of these request counts, 9, is stored in the request count field including subordinate topics. Similarly, although the number of requests assigned to topic T1-1 is 5, when the number of topics for data D5, D8, and D9, which have subordinate topics T1-1-1, is added up to 3, the total number of requests including subordinate topics becomes 8.

[0072] The learning data adjustment unit 203 extracts subtopics that have been assigned a higher level of detail than other subtopics. In this embodiment, the threshold for the number of learning data is set to 6. In this case, in the process of step S1 in Figure 4, the learning data adjustment unit 203 extracts existing requests to which topic T1-1, shown in Figure 9, is assigned as learning data 203a, which have a higher level of detail than other topics and to which at least one of the topics and subtopics extracted from the hierarchical dictionary 222 is assigned, and to which the number of existing requests is equal to or greater than the threshold. Furthermore, the process of extracting topics to which the number of requests, including subtopics, is equal to or greater than the threshold is performed in step S13 in Figure 8. Topics to which the number of requests, including subtopics, is equal to or greater than the threshold (for example, topic "T1-1: Torque control accuracy") are used for classification learning of higher-level topics (for example, topic "T1: Torque control"). Therefore, even if the new requirement R2 does not contain the phrase "torque control," classification model 204a can still classify it as having the topic "T1: Torque control" and the subtopic "T1-1: Torque control accuracy."

[0073] On the other hand, detailed topics with a number of requests including subtopics that is below a threshold (for example, the subtopic "T1-1-1: Torque rise time") are used for classification learning of higher-level topics with a number of requests including subtopics that is above a threshold. For example, even if the new request R2 does not contain the phrase "torque control accuracy," if it contains "torque rise time," the classification model 204a can classify that request R2 as having the topic "T1-1: Torque control accuracy."

[0074] Figure 10 shows an example of extracting a portion of the request topic DB221 and an example of extracting a portion of the training data 203a. The upper part of Figure 10 shows an example focusing on the records of data D1, D2, and D3 from the request topic DB221 shown in Figure 5. Based on these records, in the process of step S1 in Figure 4, the request records with topic T1-1, which has been extracted as a topic exceeding the threshold, are extracted as training data 203a.

[0075] The lower part of Figure 10 shows the records extracted as training data 203a (an example of classification training data). Requests containing topics with a data count above a threshold, extracted in step S13 of Figure 8, are extracted as classification training data. For example, as records of a request with topic T1-1, data D2 and D3 are extracted from the request topic DB221 shown at the top of Figure 10. Note that in training data 203a, the data IDs are reassigned, so data D2 and D3 extracted from the request topic DB221 are reassigned to data D1 and D2, respectively. In addition, fields such as project ID, topic ID detail level 1, and topic ID detail level 3, which are not needed for training, are removed from the request topic DB221.

[0076] <Example of a process for classifying topic candidates by level of detail> Next, the process by which the topic assignment unit 201 classifies topic candidates by level of detail and assigns a degree of certainty to the topic candidates will be explained with reference to Figures 11 to 13.

[0077] Figure 11 shows an example of the configuration of the requirement 211 to be analyzed. As shown in Figure 2, the display input unit 206 outputs the analysis target request 211 to the evaluation unit 205. The analysis target request 211 is data with a new project ID of P2 and request IDs R1 and R2, as shown in Figure 3. The analysis target request 211 consists of the fields for request ID and request statement.

[0078] The Request ID field stores a unique Request ID for each request. For example, R1 and R2 are stored as Request IDs. The request statement field stores the request statement.

[0079] <Example configuration of requests + topic suggestions (automatic)> Figure 12 shows an example of the configuration of the requirement + topic candidate (automatic) 212. As shown in Figure 2, the requirement + topic candidate (automatic) 212 represents the result of the evaluation unit 205 assigning topic candidates to the analysis target requirement 211 using a classification model. The requirement + topic candidate (automatic) 212 consists of the fields requirement ID, project ID, topic ID candidate, level of detail, and probability.

[0080] The Request ID field stores the Request ID. For example, it stores Request R1 (an example of the first request) of Request 211 being analyzed. Note that the illustration and explanation of the record with Request ID R2 are omitted. The Project ID field stores the new project ID. For example, the new project P2 entered in the new project ID input section 31 in Figure 3 is stored in the Project ID field.

[0081] The Topic ID Candidate field stores candidate topic IDs automatically classified by the evaluation unit 205 using the classification model 204a. For example, the Topic ID Candidate field stores topics T1, T1-1, T1-12, and T3. The detail field stores the detail level for each topic. The detail level for each topic is assigned by referring to the hierarchical dictionary 222. For example, if topic T1, the detail field will store a detail level of 1, and if topic T1-1, the detail field will store a detail level of 2. The probability field stores the calculated probability for each topic. The probability is indicated by values ​​ranging from 0.0 to 1.0, for example. A high probability indicates that the topic can be attached to the request statement. Note that topics with a probability of 0.1 or less are not candidates for being attached to the request, so the request + topic candidate (automatic) 212 will not have that topic added.

[0082] In this way, the evaluation unit 205 automatically assigns topic candidates to the request ID up to a level of detail that the classification model can classify, and further assigns a certainty level to each topic classified by level of detail. The evaluation unit 205 does not assign topic candidates whose certainty level is below a threshold to the request ID. For example, if the certainty threshold is 0.3, topic T3, a topic ID candidate, will not be assigned to the request ID.

[0083] <Example of output processing for requests + topic candidates (automatic + dictionary)> Next, an example of the output processing of the request + topic candidate (automatic + dictionary) 213 performed by the topic assignment unit 201 will be explained with reference to Figure 13.

[0084] Figure 13 is a flowchart showing an example of the output processing of a request + topic candidate (automatic + dictionary) 213. This process shows the details of the process in step S4 of Figure 4. The topic assignment unit 201 assigns a level of detail obtained from the hierarchical dictionary 222 to each topic candidate in a new request to which a topic candidate has been assigned.

[0085] First, the topic assignment unit 201 waits for input of a request + topic candidate (automatic) 212 from the evaluation unit 205 (S21). Once the request + topic candidate (automatic) 212 is input, the unit starts the first loop processing and the second loop processing for each new request ID and each topic candidate thereafter.

[0086] In the first loop process, the topic assignment unit 201 performs loop processing for each new request ID in the new project (S22). Once the topic assignment unit 201 selects a new request ID, it proceeds to the second loop process.

[0087] In the second loop process, the topic assignment unit 201 performs a loop process for each topic candidate (topic ID candidate shown in Figure 14, described later) assigned to the new request ID (S23). When the topic assignment unit 201 extracts a topic candidate, it searches the hierarchical dictionary 222 and extracts the topics below the current topic candidate (S24). For example, if the current topic candidate is T1, then the lower topics extracted are T1-1, T1-1-1, and T1-2. Topic T1-1-1 is a topic that has been extracted for the first time.

[0088] Next, the topic assignment unit 201 adds the subordinate topics extracted in step S24 to the list of topic candidates to be assigned to the current request (S25). For example, if the current request is R1, the subordinate topics T1-1, T1-1-1, and T1-2 are assigned to the current request.

[0089] The topic assignment unit 201 adds a subordinate topic, then returns to step S23 (S26) to select the next topic candidate (S23). Subsequently, it repeats the process in steps S24 and S25 until there are no more topic candidates to assign to the new request ID. For example, if the next topic candidate is T3, the extracted subordinate topic is T3-1, so topic T3-1 is assigned to topic candidate topic T3.

[0090] If there are no more pick candidates that can be added to a topic during the processing in steps S23 to S26, the topic assignment unit 201 returns to step S22 (S27) and selects the next new request ID (S22). The topic assignment unit 201 repeats the loop processing of steps S22 to S27 until there are no more new request IDs. When there are no more new request IDs in the new project, the process moves to step S28.

[0091] In step S28, the topic assignment unit 201 outputs the request + topic candidate (automatic + dictionary) 213 to the display input unit 206 and terminates this process. The display input unit 206 displays the topic ID of the topic that has been automatically assigned and associated with the new request ID to the request topic screen 30 shown in Figure 3.

[0092] <Example of a request + topic suggestion (automatic + dictionary) configuration> Next, an example of the configuration of the request + topic candidate (automatic + dictionary) 213 created in step S3 of Figure 4 will be explained with reference to Figure 14. Figure 14 shows example configurations of Request + Topic Candidate (Automatic) 212 and Request + Topic Candidate (Automatic + Dictionary) 213.

[0093] The upper part of Figure 14 shows an example of the data structure for Request + Topic Candidate (Automatic) 212. The example of the data structure for Request + Topic Candidate (Automatic) 212 has already been explained with reference to Figure 12.

[0094] The lower part of Figure 14 shows an example of the data structure of a request + topic candidate (automatic + dictionary) 213, to which a topic ID candidate has been assigned by the topic assignment unit 201. The field structure of the request + topic candidate (automatic) 213 is the same as the field structure of the request + topic candidate (automatic) 212.

[0095] The topic ID candidate field of the request + topic candidate (automatic) 213 stores the topic ID candidates that the evaluation unit 205 has automatically classified using the classification model. For example, the topic ID candidate field stores topics T1, T1-1, T1-12, and T3, as well as topics T1-1-1 and T3-1 that have been added by the topic assignment unit 201.

[0096] The detail field stores the detail level for each topic. The added topic T1-1-1 will have a detail level of 3, and topic T3-1 will have a detail level of 2. The probability field stores the probability calculated for each topic. However, topics T1-1-1 and T3-1 are topics extracted from the hierarchical dictionary 222, so both are stored with a probability of 0. Even with a probability of 0, it is possible to assign the most detailed topic possible to a candidate topic with high priority. For example, in the topic candidate display unit 37 of Figure 3, detailed topics with high priority and the highest possible level of detail are displayed as topic candidates. Therefore, the user can judge the validity of the highly detailed topic assigned to the new request.

[0097] Before processing by the topic assignment unit 201, the evaluation unit 205 assigns topic candidates up to "T1-1: Torque control accuracy" for request R1. Therefore, the topic assignment unit 201 searches the hierarchical dictionary 222 and adds the topic "T1-1-1: Torque rise time," which is a subordinate topic to topic T1-1, to the topic candidates. Similarly, since the evaluation unit 205 assigns topic candidates up to "T3: Rotational speed control" for request R1, the topic assignment unit 201 adds the topic "T3-1: Rotational speed control accuracy," which is a subordinate topic to topic T3, to the topic candidates.

[0098] Furthermore, the topic assignment unit 201 sets the accuracy of topic candidates extracted from the hierarchical dictionary 222 to 0, and determines priority based on the average accuracy of topic combinations, or the level of detail assigned to each topic. Subsequently, the request + topic candidates (automatic + dictionary) 213 is output to the display input unit 206, and as shown in Figure 3, topic candidates are presented to the user in order of priority.

[0099] <Example configuration of the request topic database where requests with determined topics have been added> Figure 15 shows an example of the configuration of the request topic DB221, which includes topics assigned to the request for the new project P2. The field configuration of the request topic DB221 has already been explained with reference to Figure 5.

[0100] When a user presses the topic assignment completion section 33 on the request topic screen 30 shown in Figure 3 to indicate completion of topic assignment, the topic selected on the request topic screen 30 is assigned to the request and stored in the request topic DB 221. Therefore, in step S6 of Figure 4, the request 214 (see Figure 2) with the determined topic is added to the request topic DB 221 shown in Figure 5.

[0101] Request 214, for which a topic has been determined and added to Request Topic DB221, is represented as data D11 and D12. Both data D11 and D12 have a project ID of P2. Additionally, a request statement is added to Request Topic DB221. The topic ID for the request statement in data D11 with a level of detail of 1 is topic T1. The topic ID for the request statement in data D12 with a level of detail of 1 is topic T2, the topic ID for a level of detail of 2 is topic T2-1, and the topic ID for a level of detail of 3 is topic T2-1-1.

[0102] <Example of the topic difference display screen> Figure 16 shows an example of the display of the topic difference display screen 40 shown on the display device 18 by the display input unit 206. The display input unit 206 displays the differences between topics on the topic difference display screen 40. The topic difference display screen 40 may be provided on the same page as the topic difference display screen 40 shown in Figure 3, and can be moved by scrolling. The topic difference display screen 40 includes a project ID input unit 41, a request comparison start unit 42, a topic difference display unit 43, and a detailed topic difference display unit 44 for each topic.

[0103] The Project ID Input Section 41 is provided with an input form where the user can enter the project IDs of the topics to be compared. For example, P2 is entered as a new project ID in the upper section of the Project ID Input Section 41, and P1 is entered as an existing project ID in the lower section. After the user enters the project IDs in the Project ID Input Section 41, they press the Request Comparison Start Section 42.

[0104] When the request comparison start unit 42 is pressed, a project ID comparison start instruction 206a is output from the display input unit 206 to the topic difference comparison unit 202, as shown in Figure 2. The topic differences output from the topic difference comparison unit 202 to the display input unit 206 in response to the project ID comparison start instruction 206a are used to identify functions that need to be newly developed in a new project and functions that will no longer be needed.

[0105] The topic difference comparison unit 202 uses not only "new requests" but also "existing requests" in request comparison. Therefore, the topic difference comparison unit 202 inputs project ID 202a into the request topic DB 221, reads the topics, and compares the differences between topics in new and existing projects. Based on the comparison results of the topic difference comparison unit 202, for example, the differences in topics and the differences in detailed topics for each topic, the topics are classified as "present in both existing and new," "present only in existing," or "present only in new."

[0106] The topic difference display section 43 shows topics that exist in both the existing and new projects, topics that exist only in the existing project, and topics that exist only in the new project. For example, the topics that exist in both the existing and new projects are "T1: Torque Control" and "T2: Wake up". The topic that exists only in the existing project is "T3: Rotation Speed ​​Control". Topics that exist only in the new project do not exist, as indicated by "(None)".

[0107] The detailed topic difference display section 44 for each topic shows detailed topics that exist in both the existing and new projects, detailed topics that exist only in the existing project, and detailed topics that exist only in the new project, for topics with a level of detail of 1. For example, in "T1: Torque Control," there are no detailed topics that exist in both the existing and new projects. On the other hand, in "T2: Wake up," it is shown that the detailed topic that exists in both the existing and new projects is "T2-1: Trigger CAN."

[0108] Furthermore, in "T1: Torque Control," it is shown that the detailed topics present only in existing projects are "T1-1: Torque Control Accuracy" and "T1-1-1: Torque Rise Time." On the other hand, in "T2: Wake Up," there are no detailed topics present only in existing projects. Also, in "T1: Torque Control," there are no detailed topics present only in new projects, but in "T2: Wake Up," it is shown that the detailed topic present only in new projects is "T2-1-1: CAN wake up time."

[0109] <Example of processing in the topic difference comparison section> Figures 17 and 18 are flowcharts illustrating an example of the processing performed by the topic difference comparison unit 202. The topic difference comparison unit 202 compares the topic assigned to the first request (existing request) with the topic assigned to the second request (new request) for each level to which the topic belongs, and calculates the difference between the topics.

[0110] First, the topic difference comparison unit 202 receives input of the project IDs to be compared and a comparison start instruction 206a from the user (S31). The project IDs to be compared are the project IDs of the existing project and the new project entered in the project ID input unit 41 of the topic difference display screen 40 shown in Figure 16. The comparison start instruction 206a is input from the display input unit 206 to the topic difference comparison unit 202 when the user presses the request comparison start unit 42 on the topic difference display screen 40.

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

[0112] Next, the topic difference comparison unit 202 performs a loop process for each existing request ID. In this loop process, the processes in steps S33 to S38 are repeated (S33). First, the topic difference comparison unit 202 extracts the topics attached to the existing request (S34).

[0113] Next, the topic difference comparison unit 202 determines whether the extracted topic exists in the topic comparison list 230 shown in Figure 19, which will be described later (S35). The topic comparison list 230 is a list representing the difference 215 between the new and existing requests shown in Figure 2. If the extracted topic exists in the topic comparison list 230 (YES in S35), the topic difference comparison unit 202 proceeds to step S37.

[0114] On the other hand, if the extracted topic does not exist 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 the topic field of an existing request that is temporarily set up in the topic comparison list 230.

[0115] After the YES determination in step S35, or after step S36, the topic difference comparison unit 202 sets an existing request flag for the extracted topic to indicate that this topic is included in an existing request (S37). Next, the topic difference comparison unit 202 determines whether the loop processing has been completed for all existing request IDs (S38). If the loop processing has not been completed for all existing request IDs, the topic difference comparison unit 202 selects the next existing request ID (S33) and repeats the loop processing. On the other hand, if the loop processing has been completed for all existing request IDs, the topic difference comparison unit 202 proceeds to step S39 in Figure 18, which is connected to connector A.

[0116] Next, the topic difference comparison unit 202 performs a loop process for each new request ID. In this loop process, the processes in steps S39 to S44 are repeated (S39 in Figure 18). First, the topic difference comparison unit 202 extracts the topic attached to the new request (S40).

[0117] Next, the topic difference comparison unit 202 determines whether the extracted topic exists in the topic comparison list 230 shown in Figure 19, which will be described later (S41). If the extracted topic exists in the topic comparison list 230 (YES in S41), the topic difference comparison unit 202 proceeds to step S43.

[0118] On the other hand, if the extracted topic does not exist 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 a new request that is temporarily set up in the topic comparison list 230.

[0119] After the YES determination in step S41, or after step S42, the topic difference comparison unit 202 sets a new request flag for the extracted topic to indicate that this topic is included in the new request (S43). Next, the topic difference comparison unit 202 determines whether the loop processing has been completed for all new request IDs (S44). If the loop processing has not been completed for all new request IDs, the topic difference comparison unit 202 selects the next new request ID (S39) and repeats the loop processing. On the other hand, if the loop processing has been completed for all new request IDs, the topic difference comparison unit 202 proceeds to step S45.

[0120] The topic difference comparison unit 202 classifies the topics assigned to the first request (existing request) and the topics assigned to the second request (new request) into one of the following categories: topics assigned to both the first request (existing request) and the second request (new request), topics included only in the first request (existing request), or topics included only in the second request (new request). The result of this classification is obtained as the topic difference. For example, the topic difference comparison unit 202 classifies the topics into "both," "existing only," or "new only" based on the existing request flag and the new request flag information (S45). Finally, the topic difference comparison unit 202 checks the level of detail of each topic from the hierarchical dictionary 222, outputs the topic difference and the difference of detailed topics for each topic (S46), and terminates this process.

[0121] <Example of a topic comparison list> Next, an example of topic comparison list 230 will be explained with reference to Figure 19. Figure 19 shows the process of generating the topic comparison list. Here, we will first explain (1) an example of an existing request and (2) an example of a new request extracted by the topic difference comparison unit 202, and then explain the topic comparison list 230.

[0122] (1) Examples of existing requests extracted by the topic difference comparison unit 202 The topic difference comparison unit 202 extracts existing requests from the request topic DB 221 shown in Figure 15. The field structure of the extracted existing requests is the same as that of the request topic DB 221. For example, data with existing project ID P1 is extracted from the request topic DB 221.

[0123] (2) Examples of new requests extracted by the topic difference comparison unit 202 The topic difference comparison unit 202 extracts new requests from the request topic DB 221 shown in Figure 15. The field structure of the extracted new requests is the same as that of the request topic DB 221. For example, data with a new project ID of P2 is extracted from the request topic DB 221.

[0124] An example of a topic comparison list 230 is shown at the bottom of Figure 19. The topic comparison list 230 consists of the following fields: topic ID, whether it is included in an existing request, whether it is included in a new request, and the classification result.

[0125] The Topic ID field stores the Topic ID of each topic included in new and existing requests. The "Included in Existing Requests" field will store "YES" if the topic is included in existing requests, and "NO" if the topic is not included in existing requests. The "Included in New Request" field will store "YES" if the topic is included in the new request, and "NO" if the topic is not included in the new request. The classification result field stores the classification result obtained by the topic difference comparison unit 202, which classifies topics based on flag information.

[0126] For example, a topic with topic ID T1 is included in both existing and new requests, so the classification result will be "both". Topics with topic IDs T1-1, T1-1-1, and T3 are included only in existing requests, so the classification result will be "existing only". Topics with topic ID T2-1-1 are included only in new requests, so the classification result is "New only".

[0127] The topic IDs classified in this way are displayed in the detailed topic difference display section 44 for each topic in Figure 16. This makes it easier for users to check detailed topics that exist in both existing and new projects, detailed topics that exist only in existing projects, and detailed topics that exist only in new projects.

[0128] In the requirements analysis system 1 according to the embodiment described above, topics with defined levels of detail are automatically assigned to requirements, and the topics assigned to the requirements are displayed on the requirements topic screen 30. Furthermore, for requirements that have been automatically classified by topic, the analysis results obtained by automatically analyzing the similarity and differences between topics assigned to existing requirements are displayed on the topic difference display screen 40. This makes it easy for users to repeatedly add their own opinions and run further automatic analysis. In addition, even if the level of detail of requirements differs among customers, the requirements analysis system 1 extracts and classifies topics from those requirements, making it easier for users to understand the topics included in the requirements.

[0129] While the more detailed a topic is, the clearer its meaning becomes, it presents the challenge of reducing the number of documents (training data) that share the same topic. To address this, the requirements analysis system 1 according to one embodiment provides a hierarchical dictionary 222 in which classification candidates are defined in a hierarchical structure from general information to detailed information. The training data adjustment unit 203 uses topics for which the number of requests, including lower-level topics, is equal to or greater than a threshold, calculated based on the level of detail defined for each topic in the hierarchical dictionary 222, as training data 203a. Therefore, if there is little training data for detailed topics in lower levels defined in the hierarchical dictionary 222, the training data adjustment unit 203 can automatically adjust the number of detailed topics so that they are used for training classification candidates for topics in higher levels. Furthermore, the training data adjustment unit 203 does not classify topics with low classification confidence and a small amount of data. Therefore, the training data adjustment unit 203 can create training data 203a that is appropriate for creating the classification model 204a.

[0130] Furthermore, by including an appropriate number of topics in the training data 203a, the amount of data that the classification model training unit 204 can learn from increases, improving the accuracy of the classification model 204a. The evaluation unit 205 uses the classification model 204a, trained using the training data 203a with an adjusted number of topics, to classify the topics included in the new request. As a result, the accuracy of the classification model 204a in automatically classifying detailed topics also improves.

[0131] The requirements topic screen 30 presents the user with detailed subtopics of automatically classified information. The topics assigned to requirements are classified by level of detail based on the hierarchical dictionary 222. By looking at the requirements topic screen 30, users can easily understand the relationships between different topics. As described above, the requirements analysis system 1 automatically assigns topics to requirements for new projects and classifies those topics. The user only needs to rearrange requirements within a topic or change topics to requirements.

[0132] The topic difference display screen 40 shows the differences in topics and the differences in detailed topics for each topic. From documents containing many requirements for each project, topics are extracted for each requirement in the existing and new projects, and how those topics are included in the requirements of the existing and new projects is shown. This makes it easier for users to understand the classification results of topics included in the requirements of the new project, enabling them to take appropriate action on the new project. In addition, the comparison results of topics in the existing and new requirements make it easier for users to identify topics that are not included in the existing requirements, or topics that are in the existing requirements but are unnecessary.

[0133] [Differentiation] In the embodiment described above, the project IDs of the existing project and the new project were entered into the project ID input section 41 of the topic difference display screen 40 shown in Figure 16, but other project IDs may be entered. For example, the requirements of multiple existing projects and the new project may be compared. Alternatively, assets that include variability in the contents of multiple projects may be compared.

[0134] Furthermore, the requirements analysis system 1 according to this embodiment can also be configured to use a classification model acquired from another requirements analysis system and to further train that classification model. In this configuration, the time required to adapt the classification model to the requirements of the project targeted by the requirements analysis system 1 according to this embodiment can be significantly reduced compared to the time required to build the classification model from scratch.

[0135] Furthermore, existing documents and new documents may be used in the same project and may be different versions of the documents. In this case, the existing document may be an example of the first version (older version), and the new document may be an example of the second version (newer version) which is newer than the first version.

[0136] Furthermore, while the embodiments described above illustrate the application of the present invention to projects and requirements in product development related to vehicle control, the present invention can also be applied to other technical fields. For example, the present invention may be applied to the development of financial, telecommunications, and information systems, which require a vast amount of documentation for each project.

[0137] The present invention is not limited to the embodiments described above, and of course, various other applications and modifications can be taken as long as they do not depart from the gist of the present invention as described in the claims. For example, the embodiments described above are detailed and specific explanations of the system configuration in order to clearly illustrate the present invention, and are not necessarily limited to having all the configurations described. Furthermore, it is possible to add, delete, or replace some of the configurations in these embodiments with other configurations. Furthermore, the control lines and information lines shown are those deemed necessary for explanatory purposes, and not all control lines and information lines are necessarily shown in the actual product. In reality, it is safe to assume that almost all components are interconnected. [Explanation of Symbols]

[0138] 1…Requirements analysis system, 10…Client PC, 15…Requirements analysis tool, 20…Requirements analysis server, 26…Requirements analysis program, 30…Requirements topic screen, 40…Topic difference display screen, 201…Topic assignment unit, 202…Topic difference comparison unit, 203…Training data adjustment unit, 204…Classification model learning unit, 205…Evaluation unit, 206…Display input unit, 221…Requirements topic DB, 222…Hierarchical dictionary

Claims

1. A request topic database that stores one or more first requests described in a first document, and topics assigned to the first requests, A hierarchical dictionary that stores multiple topics along with a level of detail representing the hierarchical structure of the topics, A learning data adjustment unit extracts subordinate topics belonging to a lower hierarchy than the topics assigned to the first request, based on the first request obtained from the request topic database, the topics assigned to the first request, and the hierarchical dictionary, and outputs the first requests to which the number of first requests to which at least one of the topics and subordinate topics is assigned is equal to or greater than a threshold, as learning data used to train a classification model that assigns candidate topics to one or more second requests described in the second document to be analyzed, and the number of topics is adjusted. A learning unit that uses the aforementioned training data as input to create the aforementioned classification model, A topic candidate assignment unit inputs the second request to the classification model and assigns topic candidates to the second request, The system includes a topic assignment unit that, in response to the second request to which the aforementioned topic candidates have been assigned, assigns the subordinate topics to each of the topic candidates obtained from the hierarchical dictionary. Requirements analysis system.

2. The hierarchical dictionary stores the topic and the subtopics, along with the level of detail assigned to each level. The learning data adjustment unit extracts the subtopics to which a higher level of detail has been assigned compared to other subtopics. The requirements analysis system according to claim 1.

3. The system includes a display input unit that displays the candidate topics on the requested topic screen according to their level of detail and priority, and when a topic assignment operation is input to replace one of the candidate topics with another topic, outputs the second request in which the candidate topic has been replaced with the other topic to the topic candidate assignment unit. The requirements analysis system according to claim 2.

4. The topic candidate assignment unit inputs the second request, in which the topic candidate has been replaced with the other topic, back into the classification model, and assigns the topic candidate selected by the classification model to the second request. When the display input unit receives an instruction to complete the topic assignment operation, it stores the combination of the second request and the candidate topic assigned to the second request in the request topic database. The requirements analysis system according to claim 3.

5. The system includes a topic difference comparison unit that compares the topic assigned to the first request with the topic assigned to the second request for each hierarchy to which the topic belongs, and calculates the difference between the topics. The requirements analysis system according to claim 4.

6. The topic difference comparison unit classifies the topics assigned to the first request and the topics assigned to the second request into one of the following categories: topics assigned to both the first and second requests, topics included only in the first request, or topics included only in the second request. The result of this classification is determined as the difference between the topics. The requirements analysis system according to claim 5.

7. The display input unit displays the differences of the topics on the topic difference display screen. The requirements analysis system according to claim 6.

8. The first document is an existing document used in a past project, and the second document is a new document used in a new project. The requirements analysis system according to claim 6.

9. The first document is the first version of the document, and the second document is the second version, which is newer than the first version. The requirements analysis system according to claim 6.

10. The requirements analysis system's learning data adjustment unit extracts subordinate topics belonging to a lower hierarchy than the topics assigned to the first requirements, based on a hierarchical dictionary that records one or more first requirements described in a first document and topics assigned to the first requirements, obtained from a requirements topic database, and a plurality of the topics along with the level of detail assigned to the topics. The first requirements to which the number of first requirements to which at least one of the topics and subordinate topics is assigned are equal to or greater than a threshold, and these first requirements are output as learning data in which the number of topics is adjusted, and used for training a classification model that assigns candidate topics to one or more second requirements described in a second document to be analyzed. The steps include creating the classification model using the aforementioned training data as input, The steps include inputting the second request into the classification model and assigning candidate topics to the second request, The second request to which the aforementioned topic candidates have been assigned includes the step of assigning the subordinate topics to each of the topic candidates obtained from the hierarchical dictionary. Requirements analysis method.

Images