Request analysis system and request 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

Requirements analysis system and requirements analysis method

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

[0002] When developing a product, customers make a variety of requests, so product developers must analyze these requests to understand what features they require. For example, developers previously analyzed customer requirements by considering which requirements to categorize for each product function, or by identifying the differences between existing products and the features mentioned in the requirements. However, because customer requirements are written in a variety of documents with many pages, automation of analysis work using machine learning is advancing in order to perform customer requirements analysis more quickly and accurately than before.

[0003] In order to automatically determine and classify the functions and features related to customer requests, it is necessary to train a classification algorithm using machine learning. In order to improve the accuracy of automatic classification, it is necessary to create training data in which classification result information is correctly assigned to requests. Classification result information is information that represents the results of classifying functions or features (hereinafter referred to as "topics") for requests made in the past.

[0004] Patent Document 1 states, "When classifying a plurality of documents into clusters using words contained in the documents, the learning device assigns a label to each word used to classify the clusters. The learning device classifies a plurality of documents into clusters using the labels assigned to each word. Furthermore, when a cluster classified using a first word and a cluster classified using a second word are similar, the learning device assigns a label that is common to the label assigned to the first word to the second label."

[0005] JP 2018-169940 A

[0006] However, if there is not enough training data, the accuracy of automatic classification will decrease, and the classification algorithm will make an incorrect classification decision. In this case, the topic classification results from machine learning will be incorrect, and customer requests will not be classified correctly. Furthermore, the more detailed a topic is, the clearer the meaning of the topic will be, but the number of documents with the same topic, i.e., the number of customer requests, will decrease. For this reason, a mechanism is needed for a machine learning device to learn the content classified by users (e.g., designers) as part of their daily work as training data and feed it back into automatic classification, but learning from this perspective has not been carried out in the past.

[0007] Furthermore, the topics required vary depending on the client, and even for the same client, depending on the development project. For example, client A may define requirements in detail, while client B may only define them at an outline level. Because the granularity of requirements varies from client to client, simply comparing requirements makes it difficult to identify topics to reuse or create new ones based on consistency with existing requirements. Patent Document 1 also describes integrating multiple labeled words into a single cluster, but automatic topic classification using this type of integration alone is difficult.

[0008] The present invention has been made in consideration of these circumstances, and aims to adjust the learning data used to train a classification model that classifies requests, assign appropriate topics to requests, and classify the requests.

[0009] a learning data adjustment unit that extracts subtopics that belong to a lower hierarchy than the topic assigned to the first request based on the first request and the topic assigned to the first request obtained from the request topic database and the hierarchical dictionary, and outputs the first request assigned with a topic where the number of first requests to which at least one of the subtopics is assigned is equal to or greater than a threshold value as learning data for adjusting the number of topics; a learning unit that uses the learning data as input to create a classification model; a topic candidate assignment unit that inputs the second request to the classification model and assigns topic candidates to the second request; and a topic assignment unit that assigns subtopics of the topic candidates obtained from the hierarchical dictionary to each of the second requests to which topic candidates have been assigned.

[0010] According to the present invention, a classification model created by adjusting the learning data used to train the classification model can assign subtopics to the topic candidates assigned to the second request, thereby classifying the request.

[0011] 1 is a block diagram showing an example of the hardware configuration of a requirement analysis system according to an embodiment of the present invention. FIG. 2 is a block diagram showing an example of the functional configuration of a requirement analysis system according to an embodiment of the present invention. FIG. 3 is a diagram showing an example of the configuration of a requirement topic screen displayed on a display device by a display input unit according to an embodiment of the present invention. FIG. 4 is a flowchart showing an example of the processing of a requirement analysis program according to an embodiment of the present invention. FIG. 5 is a diagram showing an example of the configuration of a requirement topic DB including topics assigned to requirements of an existing project according to an embodiment of the present invention. FIG. 6 is a diagram showing an example of the configuration of a hierarchical dictionary according to an embodiment of the present invention. FIG. 7 is a diagram showing the relationship between the hierarchical structure of topics and the level of detail according to an embodiment of the present invention. FIG. 8 is a flowchart showing an example of the processing of a learning data adjuster according to an embodiment of the present invention. FIG. 9 is a diagram showing a calculation result of the number of requests for each topic ID according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of an extracted portion of the request topic DB and an example of a portion of learning data. FIG. 11 is a diagram showing an example of the configuration of a requirement to be analyzed according to an embodiment of the present invention. FIG. 12 is a flowchart showing an example of output processing of requirement + topic candidate (automatic) according to an embodiment of the present invention. FIG. 13 is a diagram showing example configurations of requirement + topic candidate (automatic) and requirement + topic candidate (automatic + dictionary) according to an embodiment of the present invention. FIG. 14 is a diagram showing an example of the configuration of a requirement topic DB including topics assigned to requirements of a new project according to an embodiment of the present invention. FIG. 15 is a diagram showing an example of a topic difference display screen displayed on a display device by a display input unit according to an embodiment of the present invention. 1 is a flowchart showing an example (first half) of the processing of a topic difference comparison unit according to one embodiment of the present invention; FIG. 2 is a flowchart showing an example (second half) of the processing of a topic difference comparison unit according to one embodiment of the present invention; FIG. 3 is a diagram showing a process of generating a topic comparison list according to one embodiment of the present invention.

[0012] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and redundant description will be omitted.

[0013] [One embodiment] <Hardware configuration example of a requirement analysis system> First, a hardware configuration example of a requirement analysis system 1 will be described with reference to Fig. 1. Fig. 1 is a block diagram showing a hardware configuration example of a requirement analysis system 1 according to one 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 are configured as a server-client system. For example, the client PC 10 can access the requirement analysis server 20, which is configured on-premise, via a communication line such as a LAN (Local Area Network). However, the requirement analysis server 20 may also be configured as a virtual machine on the cloud. In this case, the client PC 10 can access the requirement analysis server 20 via an external network such as the Internet. Furthermore, the client PC 10 may have only an input device 17 and a display device 18, and the classification results of the requirement analysis performed by the requirement analysis server 20 can be confirmed via a web browser.

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

[0016] The CPU 11 reads out from the ROM 14 the program code of the software (for example, the requirements analysis tool 15) that realizes each function according to this embodiment, loads it into the RAM 12, and executes it. Variables, parameters, etc. that arise during the calculation processing of the CPU 11 are temporarily written to the RAM 12, and these variables, parameters, etc. 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 allows the user to input data or check the screen.

[0017] The storage 13 is a non-volatile storage medium that stores an operating system (OS), various parameters, and programs for running the client PC 10. The storage 13 may be, for example, a hard disk drive (HDD), a solid state drive (SSD), or a non-volatile memory. The storage 13 and the ROM 14 store programs and data necessary for the CPU 11 to operate, and are used as an example of a computer-readable, non-transitory storage medium that stores programs executed by the client PC 10.

[0018] The network interface 16 may be, for example, a NIC (Network Interface Card), and various data may be sent and received with the request analysis server 20 via a LAN, a dedicated line, or an Internet communication line connected to the NIC terminal.

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

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

[0021] The server CPU 21 reads software program code (e.g., a requirements analysis program 26) that realizes each function according to this embodiment from the server ROM 25, loads it into the server RAM 22, and executes it. Variables, parameters, etc. generated during the server CPU 21's arithmetic processing are temporarily written to the server RAM 22, and these variables, parameters, etc. are read by the server CPU 21 as appropriate. The requirements analysis program 26 is a software program executable by the requirements analysis server 20 and provides various functions according to this embodiment, as shown in FIG. 2 (described later). For example, both existing projects and new projects contain numerous documents, each with multiple requirements 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 include, for example, keywords, annotations, notes, etc., that are added to documents in which requirements are described.

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

[0023] The server network interface 24 may be implemented by a NIC or the like, and can transmit and receive various data to and from the client PC 10 via a LAN, dedicated line, or Internet communication line connected to the NIC terminal.

[0024] 1 shows an example in which the requirement analysis system 1 is configured with the client PC 10 and the requirement analysis server 20, but the functions of the requirement analysis server 20 may be incorporated into one client PC 10. In this case, the client PC 10 is configured as a standalone system, and the requirement analysis tool 15 performs the functions of the requirement analysis program 26.

[0025] <Example of Functional Configuration of Requirement Analysis System> Next, an example of the functional configuration of the requirement analysis system 1 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the functional configuration of the requirement analysis system 1. The contents of each functional block shown in Fig. 2 will be described with reference to Fig. 3 and subsequent figures. Note that each functional block shown in Fig. 2 is configured in the requirement analysis program 26 shown in Fig. 1, and each database is configured in the server storage 23 shown in Fig. 1. Furthermore, various data created in each functional block is temporarily stored in the server RAM 22 shown in Fig. 1 and is read out as appropriate.

[0026] The requirements analysis system 1 includes 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 requirement topic database (DB: Data Base) 221, and a hierarchical dictionary 222. Between the functional units, requirements to be analyzed 211, requirements + topic candidates (automatic) 212, requirements + topic candidates (automatic + dictionary) 213, requirements with topics determined 214, and differences between new and existing requirements 215 are generated.

[0027] Existing requirements are customer requirements that have been realized in past projects, and topics with different levels of detail have been assigned to the existing requirements based on the design results. This allows the requirements analysis system 1 to use the existing requirements as learning data for the classification model. On the other hand, new requirements are customer requirements to be realized in a new project, and no topics have been assigned to them. This means that new requirements are targets for automatic topic classification by the requirements analysis system 1 using the classification model, and are also referred to as analysis target requirements.

[0028] The display input unit 206 displays a screen on the client PC 10 that allows the user to input information. To this end, the display input unit 206 creates screen data that constitutes the screen and transmits it to the client PC 10 via the server network interface 24. When the requirement analysis tool 15 of the client PC 10 receives the screen data via the network interface 16, it displays a request topic screen 30 (see FIG. 3) and a topic difference display screen 40 (see FIG. 16), which will be described later, on the display device 18 based on the screen data. The display input unit 206 also passes instructions input via the screen to the requirement analysis tool 15. The requirement analysis tool 15 outputs user instructions to the requirement analysis server 20 via the network interface 16. The requirement 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 by level of detail and in order of priority, and when a topic assignment operation to replace a topic candidate with another topic is input, the display input unit 206 outputs a second request (new request: for example, the request to be analyzed 211) in which the topic candidate has been replaced with the other topic to the evaluation unit 205.

[0030] 3 is a diagram showing an example of the configuration of a requested topic screen 30 displayed on the display device 18 by the display input unit 206. The requested 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 requested topic display unit 34.

[0031] Once the user has determined the new project ID, he / she writes the new project ID in the new project ID input section 31. The new project ID is, for example, P2, and the new project includes the new requirements described above. Next, when the user clicks on the analysis target requirement reading section 32, the requirements analysis program 26 shown in FIG. 1 reads a requirement file from the requirement topic DB 221. The requirement file has the same field configuration as the requirement topic DB 221. The requirement topic DB 221 is an example of a database that stores one or more existing requirements described in an existing document (first document) and topics assigned to the existing requirements (first requirements).

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

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

[0034] For example, the first record from the top is a record that includes a requirement for an inverter system, with a requirement ID of R1 and a requirement statement of "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 and T1-2 with a level of detail of 2, and topic ID 34-3 is topics T1-1-1, ... with a level of detail of 3. In the following explanation, a "request statement" may be referred to as a "request." Furthermore, requirement R1 in existing project P1 is an existing requirement (an example of a first requirement).

[0035] The user can select a topic at each level of detail from a drop-down list provided in the topic ID field. For example, the user can select one of "T1: Torque Control," "T2: Wake Up," or "T3: Rotation Speed ​​Control" from the drop-down list for the topic "T1" with a level of detail 1. The user can also select a detailed topic from the drop-down list for topics with a level of detail 2 and a level of detail 3. The detailed topics at each level of detail correspond to the hierarchical dictionary 222 shown in FIG. 2 and FIG. 6, which will be described later.

[0036] The field for automatic classification candidates is provided with a display instruction unit 36 ​​that the user can click to display a topic candidate display unit 37 superimposed on the request topic screen 30. When the user presses the display instruction unit 36, topic candidates that have been analyzed and classified in advance by the request analysis system 1 are displayed in order of priority in the topic candidate display unit 37. The priority is determined by factors such as the accuracy of automatic classification and the number of topic candidates classified by the hierarchical dictionary 222. The hierarchical dictionary (hierarchical dictionary 222) is an example of a database that stores multiple topics together with a level of detail that represents the hierarchical structure of the topics, and the hierarchical dictionary 222 defines the hierarchy to which the topics belong.

[0037] The topic candidate display unit 37 displays topic IDs, but the content of the topics associated with the topic IDs (see FIG. 6, described later) may also be displayed. When a user selects a topic from the topic candidates displayed in the request topic display unit 34, the selected topic is automatically reflected in the row where the user pressed the display instruction unit 36. For example, for a record with a topic ID of request ID R2, the automatic classification results are displayed in a drop-down list as "T1: Torque Control," "T2: Wake Up," and "T3: Rotation Speed ​​Control." Request R2 is referred to as a new request (an example of a second request) for new project P2. When a user selects "T2: Wake Up," the detailed topics under topic T2 (topics T2-1 and T2-1-1) are displayed as topic candidates. The level to which topics can be automatically classified depends on the calculated accuracy of 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 inputs a second request (new request) to a classification model (classification model 204a) and assigns topic candidates to the second request (new request). The evaluation unit 205 also inputs the new request, in which the topic candidates have been replaced with other topics, back to the classification model 204a, and assigns the topic candidates selected by the classification model 204a to the new request. When a new request is input, the classification model 204a has the function of classifying and assigning topic candidates to be assigned to the new request based on keywords, etc., described in the new request. The new request to which the topic candidates have been assigned is again displayed on the request topic screen 30.

[0039] When the user has finished selecting a topic for the request, he / she clicks the topic assignment completion section 33. When the user clicks the topic assignment completion section 33, the display input unit 206 accepts an instruction to complete the topic assignment operation. When the display input unit 206 accepts the instruction to complete the topic assignment operation, it saves the new request and the combination of topic candidates assigned to the new request in the request topic DB 221. By configuring the request topic screen 30 in this way, for efficient request analysis, the user can classify topics, and the request analysis program 26 can easily repeat the task of learning and automatically classifying topics.

[0040] In the past, it was necessary to be able to learn content classified by users as part of their daily work as learning data and feed it back into automatic categorization. However, when users assign topics, the workload for analyzing requirements for new projects increases, which has been a constraint in that adding a task solely for the purpose of topic assignment is inappropriate. To address this issue, the requirements analysis system 1 uses the hierarchical dictionary 222 to present the user with corresponding detailed topic candidates in lower levels on the requirements topic screen 30, based on the results of automatic categorization of topics in higher levels. This allows the user to easily categorize requirements by topic and also assign more detailed topics to the requirements.

[0041] <Example of Processing of Requirement Analysis Program> Next, an example of processing of the requirement analysis program 26 will be described with reference to Fig. 2 and Fig. 4. Fig. 4 is a flowchart showing an example of processing of the requirement analysis program 26. This flowchart explains the requirement analysis method performed in the requirement analysis system 1.

[0042] First, when the learning data adjustment unit 203 detects that the requested 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. Note that the trigger for starting learning may be an instruction explicitly input by the user. Details of the processing in step S1 will be described later with reference to FIG. 8.

[0043] Next, the learning unit (classification model learning unit 204) uses the learning data (learning data 203a) as input to learn a classification model (classification model 204a) (S2). Note that learning the classification model 204a by the classification model learning unit 204 is synonymous with creating the classification model 204a. This classification model 204a is output to the evaluation unit 205.

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

[0045] Next, the evaluation unit 205 inputs a new request into the classification model 204a, and the classification model 204a outputs the new request to which topic candidates have been assigned. 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 FIG. 3, the evaluation unit 205 starts analyzing the analysis target request 211 using the classification model 204a. Thereafter, the evaluation unit 205 automatically assigns topic candidates to the analysis target request 211 using the classification model 204a (S3). This process of the classification model 204a automatically assigning topic candidates to the analysis target request 211 is called "evaluation." Note that in FIG. 12, which will be described later, topic candidates are represented by topic ID candidates.

[0046] The analysis target request 211 to which the topic candidate has been automatically assigned is output to the topic assignment unit 201 as a 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 request stored in the analysis target request 211.

[0047] Next, for the second request (new request) to which topic candidates have been assigned, the topic assigning unit 201 assigns subtopics (detailed topics) for each topic candidate obtained from the hierarchical dictionary 222. For example, the topic assigning unit 201 determines a detailed topic for the request + topic candidate (automatic) 212 based on the topic information 222a read from the hierarchical dictionary 222. The topic assigning unit 201 also adds the topic candidate and the 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. Therefore, the request + topic candidate (automatic + dictionary) 213 is output by the processing of step S4. Details of the processing of step S4 will be described later with reference to FIG. 13.

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

[0049] When the instruction to complete the topic assignment operation is received, the display input unit 206 stores the request 214 for which the topic has been determined in the requested topic DB 221 (S6), and ends this process.

[0050] <Configuration Example of Request Topic DB and Hierarchical Dictionary> Next, a configuration example of the request topic DB 221 and the hierarchical dictionary 222 will be described with reference to FIGS. 5 to 7. FIG.

[0051] 5 is a diagram showing an example of the configuration of the request topic DB 221, which contains topics assigned to requests of existing projects. The request topic DB 221 stores data including topics assigned to existing requests of past projects (e.g., project P1). The request topic DB 221 is configured with fields for 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 data ID that can identify each request statement. Data IDs D1 to D10 are assigned. The project ID field stores a project ID that can identify a past project. P1 is stored as the project ID. The request statement field stores a request statement that includes a request from a customer for a past project 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 with a detail level of 3. Note that "None" entered in each topic ID detail level field indicates that there is no corresponding topic.

[0054] 6 is a diagram showing an example of the configuration of the hierarchical dictionary 222. The hierarchical dictionary (hierarchical dictionary 222) stores topics and subtopics together with the level of detail assigned to each level. This hierarchical dictionary 222 is composed of fields for topic ID, level of detail, topic, and superordinate topic ID.

[0055] The topic ID field stores a topic ID that can be identified for each topic. For example, topics T1, T1-1, T1-1-1, T2, etc. are stored. The detail level field stores the detail level set for each topic. In FIG. 6, the detail levels are 1 to 3, but a detail level of 4 or more may be set. The topic field stores the content of the topic. For example, "torque control" and "torque control accuracy" are stored as topics. The superordinate topic ID field stores the topic ID of the superordinate topic that is one level higher than the topics in the hierarchical structure (referred to as the "superordinate topic ID"). The top-level topic does not store a superordinate topic ID, but instead stores "None."

[0056] 7 is a diagram showing the relationship between the hierarchical structure of topics and the level of detail. Here, the explanation focuses on topics T1, T1-1, T1-1-1, and T1-2. The hierarchical structure of topics is defined by recording the higher-level topic IDs in the hierarchical dictionary 222.

[0057] Topic T1, with a level of detail of 1, is the top-level topic. Therefore, nothing is stored in the superordinate topic ID field of the hierarchical dictionary 222 shown in FIG. 6. Topics T1-1 and T1-2, with a level of detail of 2, are immediately below topic T1. Therefore, topic T1 is stored in the superordinate topic ID field of both topic IDs T1-1 and T1-2 in the hierarchical dictionary 222. Topic T1-1-1, with a level of detail of 3, is immediately below topic T1-1. Therefore, topic T1-1 is stored in the superordinate topic ID field of topic ID T1-1-1 in the hierarchical dictionary 222.

[0058] A topic may have multiple higher-level topics. In this case, multiple topic IDs are stored in the higher-level topic ID field of the hierarchical dictionary 222.

[0059] <Processing of Learning Data Adjustment Unit and Example of Configuration of Learning Data> Next, the processing of the learning data adjustment unit 203 and an example of the configuration of the learning data 203a will be described with reference to FIGS. 8 and 9. FIG.

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

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

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

[0063] Next, the learning data adjustment unit 203 searches the hierarchical dictionary 222 and acquires the topic information 222c. Furthermore, each learning data adjustment unit 203 calculates the number of data items that have topics subordinate to the topic, and adds up the number of data items to which each topic is assigned (S12).

[0064] Next, the learning data adjustment unit 203 searches the hierarchical dictionary 222 to acquire topic information 222c. The learning data adjustment unit 203 also extracts topics that have a higher level of detail than the topic acquired in step S12 and for which the number of requests, including subtopics, is equal to or greater than a threshold (S13). The topic levels of detail increase in the order of 1, 2, and 3.

[0065] Finally, the learning data adjuster 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 ends this process.

[0066] 9 is a diagram showing the calculation results of the number of requests for each topic ID. Here, an example will be described in which the number of requests including a topic is calculated, assuming the topics stored in the request topic DB 221, in the process shown in step S1 of FIG. 4. The calculation results of the number of data items for each topic are composed of fields for the topic ID, the level of detail, the number of requests assigned with the topic ID, and the number of requests including subtopics.

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

[0068] The number of requests assigned to each topic is stored in the field of the number of requests assigned to each topic. The number of requests is each piece of data identified by the data ID in the request topic DB 221 shown in Fig. 5. The number of requests assigned to each topic ID corresponds to the number of data calculated in step S11 of Fig. 8.

[0069] For example, since six items of topic T1 are stored in the topic ID detail level 1 field of the requested topic DB 221, 6 is stored in the number of requests field to which the topic ID is assigned in Fig. 9. Similarly, five items of topic T1-1 are stored in the topic ID detail level 2 field of the requested topic DB 221, so 5 is stored in the number of requests field to which the topic ID is assigned in Fig. 9.

[0070] The number of requests including subtopics from the perspective of the higher-level topic is stored in the "Number of requests including subtopics" field. The number of requests including subtopics corresponds to the number of data items calculated in step S12 of FIG. 8.

[0071] For example, topic T1 is stored six times in the data ID field of the requested topic DB 221, including D1 to D6. Also, topic T1-1, which has data ID D7 and is stored in the topic ID detail level 2 field, is a lower-level topic from the perspective of topic T1, and one time is stored. 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 level of detail and is a lower-level topic from the perspective of topic T1, and two times is stored. The total number of requests for these, 9, is stored in the request count field including lower-level topics. Similarly, the number of requests assigned to topic T1-1 is five, but when the three topics of data D5, D8, and D9, which have lower-level topic T1-1-1, are added together, the total number of requests including lower-level topics is eight.

[0072] The learning data adjustment unit 203 extracts lower topics assigned with a higher level of detail than other lower topics. In this embodiment, the threshold for the number of learning data items is set to 6. In this case, in the process of step S1 in FIG. 4 , the learning data adjustment unit 203 extracts, as learning data 203a, topics that have a higher level of detail than other topics and, among the topics and lower topics extracted from the hierarchical dictionary 222, at least one of which has the number of existing requests assigned thereto equal or exceed a threshold, such as existing requests assigned with topic T1-1 shown in FIG. 9 . Furthermore, the process of extracting topics for which the number of requests, including lower topics, equal or exceed a threshold, is performed in step S13 in FIG. 8 . A topic for which the number of requests, including lower topics, equal or exceed a threshold (e.g., topic "T1-1: torque control accuracy") is used for classification learning of a higher topic (e.g., topic "T1: torque control"). Therefore, even if the phrase "torque control" is not written in the new request R2, the classification model 204a can classify it by assigning the topic "T1: torque control" and the subtopic "T1-1: torque control accuracy."

[0073] On the other hand, detailed topics for which the number of requests, including subtopics, is less than the threshold (for example, the subtopic "T1-1-1: torque rise time") are used for classification learning of higher-level topics for which the number of requests, including subtopics, is equal to or greater than the threshold. For example, even if the phrase "torque control accuracy" is not written in new request R2, if "torque rise time" is written, the classification model 204a can classify request R2 by assigning the topic "T1-1: torque control accuracy."

[0074] Fig. 10 shows an example of an extracted portion of the requested topic DB 221 and an example of a portion of the learning data 203a. The upper part of Fig. 10 shows an example focusing on the records of data D1, D2, and D3 from the requested topic DB 221 shown in Fig. 5. Based on these records, in the process of step S1 in Fig. 4, records of requests having topic T1-1 extracted as a topic exceeding the threshold are extracted as learning data 203a.

[0075] The lower part of Figure 10 shows records (examples of classification learning data) extracted as learning data 203a. Requests including topics with a data count equal to or greater than a threshold, extracted in step S13 of Figure 8, are extracted as classification learning data. For example, data D2 and D3 are extracted from the request topic DB 221 shown in the upper part of Figure 10 as records of requests having topic T1-1. Note that, since data IDs are reassigned in the learning data 203a, data D2 and D3 extracted from the request topic DB 221 are reassigned to data D1 and D2, respectively. In addition, fields for project ID, topic ID detail level 1, and topic ID detail level 3, which are not necessary for learning, are removed from the request topic DB 221.

[0076] <Example of Processing for Classifying Topic Candidates by Level of Detail> Next, processing by the topic assigning unit 201 for classifying topic candidates by level of detail and assigning degrees of certainty to the topic candidates will be described with reference to FIGS. 11 to 13. FIG.

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

[0078] The request ID field stores a request ID that can identify each request. For example, R1 and R2 are stored as request IDs. The request statement field stores a request statement.

[0079] <Configuration Example of Requirement + Topic Candidate (Automatic)> Fig. 12 is a diagram showing a configuration example of the requirement + topic candidate (automatic) 212. As shown in Fig. 2, the requirement + topic candidate (automatic) 212 represents the result of the evaluation unit 205 using a classification model to assign topic candidates to the analysis target requirement 211. The requirement + topic candidate (automatic) 212 is composed of fields for requirement ID, project ID, topic ID candidate, level of detail, and accuracy.

[0080] The requirement ID field stores a requirement ID. For example, requirement R1 (an example of the first requirement) of the analysis target requirement 211 is stored. Note that illustration and description of the record with requirement ID R2 are omitted. The project ID field stores a new project ID. For example, the new project P2 input in the new project ID input section 31 in FIG. 3 is stored in the project ID field.

[0081] The topic ID candidate field stores topic ID candidates 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 level field stores the detail level of each topic. The detail level of each topic is assigned by referring to the hierarchical dictionary 222. For example, for topic T1, a detail level of 1 is stored in the detail level field, and for topic T1-1, a detail level of 2 is stored in the detail level field. The accuracy field stores the accuracy calculated for each topic. The accuracy is indicated by a value ranging from 0.0 to 1.0, for example. A topic with a high accuracy indicates that the topic may be assigned to a request statement. Note that topics with an accuracy level of 0.1 or less are not candidates for topics to be assigned to requests, and therefore are not added to the request + topic candidate (automatic) 212.

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

[0083] <Example of Request+Topic Candidate (Automatic+Dictionary) Output Processing> Next, an example of the request+topic candidate (automatic+dictionary) 213 output processing performed by the topic assigning unit 201 will be described with reference to FIG.

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

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

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

[0087] In the second loop process, the topic assigning unit 201 performs loop processing for each topic candidate (topic ID candidate shown in FIG. 14, which will be described later) to be assigned to the new request ID (S23). When the topic assigning unit 201 extracts a topic candidate, it searches the hierarchical dictionary 222 and extracts topics lower than the current topic candidate (S24). For example, if the current topic candidate is T1, the extracted lower topics are T1-1, T1-1-1, and T1-2. Topic T1-1-1 is the first topic extracted this time.

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

[0089] After adding the subordinate topic, the topic assigning unit 201 returns to step S23 (S26) and selects the next topic candidate (S23). Thereafter, the processes of steps S24 and S25 are repeated 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, and therefore topic T3-1 is assigned to topic candidate T3.

[0090] When there are no more pick candidates that can be added to the topic in the processing of steps S23 to S26, the topic assigning unit 201 returns to step S22 (S27) and selects the next new request ID (S22). The topic assigning 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 proceeds to step S28.

[0091] In step S28, the topic assigning unit 201 outputs the request+topic candidate (automatic+dictionary) 213 to the display input unit 206, and ends this process. The display input unit 206 displays the topic ID of the automatically assigned topic linked to the new request ID on the request topic screen 30 shown in FIG.

[0092] <Configuration Example of Request + Topic Candidate (Automatic + Dictionary)> Next, a configuration example of the request + topic candidate (automatic + dictionary) 213 created in step S3 of Fig. 4 will be described with reference to Fig. 14. Fig. 14 is a diagram showing configuration examples of the request + topic candidate (automatic) 212 and the request + topic candidate (automatic + dictionary) 213.

[0093] 14 shows an example of the data structure of the request + topic candidate (automatic) 212. The example of the data structure of the request + topic candidate (automatic) 212 has already been described with reference to FIG.

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

[0095] The topic ID candidate field of the request + topic candidate (automatic) 213 stores topic ID candidates automatically classified using a classification model by the evaluation unit 205. For example, in addition to topics T1, T1-1, T1-12, and T3, the topic ID candidate field stores topics T1-1-1 and T3-1 added by the topic assigning unit 201.

[0096] The detail level field stores the detail level of each topic. The added topic T1-1-1 stores a detail level of 3, and topic T3-1 stores a detail level of 2. The accuracy field stores the accuracy calculated for each topic. However, because topics T1-1-1 and T3-1 are topics extracted from the hierarchical dictionary 222, both stores a detail level of 0. Even if the accuracy level is 0, a topic with as high a detail level as possible can be assigned to a topic candidate with high priority. For example, the topic candidate display unit 37 in FIG. 3 displays detailed topics with high priority and as high a detail level as possible as topic candidates. This allows the user to determine the appropriateness of the topic with a high detail level assigned to a new request.

[0097] Before the topic assignment unit 201 performs processing, the evaluation unit 205 assigns topic candidates up to "T1-1: Torque control accuracy" to the 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 subordinate to the topic T1-1 to the topic candidates. Similarly, the evaluation unit 205 assigns topic candidates up to "T3: Rotation speed control" to the request R1, so the topic assignment unit 201 adds the topic "T3-1: Rotation speed control accuracy" which is subordinate to the topic T3 to the topic candidates.

[0098] The topic assigning unit 201 also sets the accuracy of topic candidates extracted from the hierarchical dictionary 222 to 0, and determines priorities based on the average accuracy of topic combinations, the level of detail assigned to each topic, etc. Thereafter, the request + topic candidates (automatic + dictionary) 213 is output to the display input unit 206, and the topic candidates are presented to the user in order of priority, as shown in FIG.

[0099] <Configuration example of request topic DB to which requests with determined topics are added> Fig. 15 is a diagram showing a configuration example of the request topic DB 221 including topics assigned to requests of new project P2. The field configuration of the request topic DB 221 has already been described with reference to Fig. 5.

[0100] When the user presses the topic assignment completion section 33 on the requested topic screen 30 shown in Fig. 3 to instruct completion of topic assignment, the topic selected on the requested topic screen 30 is assigned to the request and stored in the requested topic DB 221. Therefore, in step S6 of Fig. 4, the request 214 (see Fig. 2) for which the topic has been determined is added to the requested topic DB 221 shown in Fig. 5.

[0101] The request 214 with the topic determined and added to the request topic DB 221 is represented as data D11 and D12. The project ID of both data D11 and D12 is P2. In addition, a request statement is added to the request topic DB 221. The topic ID of the request statement of data D11 with a level of detail 1 is topic T1. The topic ID of the request statement of data D12 with a level of detail 1 is topic T2, the topic ID of the level of detail 2 is topic T2-1, and the topic ID of the level of detail 3 is topic T2-1-1.

[0102] <Display Example of Topic Difference Display Screen> Fig. 16 is a diagram showing a display example of a topic difference display screen 40 displayed on the display device 18 by the display input unit 206. The display input unit 206 displays topic differences 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 Fig. 3, which 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 in which the user can input the project IDs for which topics are to be compared. For example, P2 is input in the upper section of the project ID input section 41 as a new project ID, and P1 is input in the lower section as an existing project ID. After inputting the project ID in the project ID input section 41, the user presses the request comparison start section 42.

[0104] 2, a project ID comparison start instruction 206a is output from the display input unit 206 to the topic difference comparison unit 202. In response to the project ID comparison start instruction 206a, the topic differences output from the topic difference comparison unit 202 to the display input unit 206 are used to identify functions that require new development in a new project and functions that will become unnecessary.

[0105] The topic difference comparison unit 202 uses not only "new requirements" but also "existing requirements" in the requirement comparison. For this reason, the topic difference comparison unit 202 inputs the project ID 202a into the requirement topic DB 221, reads out the topics, and compares the topic differences between the new project and the existing project. The comparison results of the topic difference comparison unit 202 are classified into "present in both existing and new projects," "present only in existing projects," and "present only in new projects" based on, for example, information on the topic differences and the detailed topic differences for each topic.

[0106] The topic difference display section 43 displays topics that are in both the existing project and the new project, topics that are only in the existing project, and topics that are only in the new project. For example, topics that are in both the existing project and the new project are "T1: Torque control" and "T2: Wake up." A topic that is only in the existing project is "T3: Rotation speed control." A topic that is only in the new project does not exist, as displayed as "(None)."

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

[0108] Additionally, for "T1: Torque control," the detailed topics that are only available in existing projects are "T1-1: Torque control accuracy, T1-1-1: Torque rise time." On the other hand, for "T2: Wake up," there are no detailed topics that are only available in existing projects. Also, for "T1: Torque control," there are no detailed topics that are only available in new projects, but for "T2: Wake up," the detailed topic that is only available in new projects is "T2-1-1: CAN wake up time."

[0109] 17 and 18 are flowcharts showing an example of the processing of 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 hierarchy to which the topic belongs, and finds the topic differences.

[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 input in the project ID input section 41 of the topic difference display screen 40 shown in Fig. 16. The comparison start instruction 206a is input to the topic difference comparison unit 202 from the display input section 206 when the user presses the request comparison start section 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 of 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 of steps S33 to S38 are repeatedly performed (S33). First, the topic difference comparison unit 202 extracts topics assigned to the existing requests (S34).

[0113] Next, the topic difference comparison unit 202 determines whether the extracted topic exists in the topic comparison list 230 shown in Fig. 19 (described later) (S35). The topic comparison list 230 is a list that shows the differences 215 between new and existing requests shown in Fig. 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 step S36, the topic difference comparison unit 202 sets an existing request flag for the extracted topic, indicating that this topic is included in the existing requests (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 FIG. 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 of steps S39 to S44 are repeatedly performed (S39 in FIG. 18). First, the topic difference comparison unit 202 extracts the topic assigned to the new request (S40).

[0117] Next, the topic difference comparison unit 202 determines whether the extracted topic is present in the topic comparison list 230 shown in Fig. 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.

[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 a 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 step S42, the topic difference comparison unit 202 sets a new request flag for the extracted topic, indicating that this topic is included in new requests (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 either 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), and determines the topic difference as the result. For example, the topic difference comparison unit 202 classifies the topics into "both," "existing only," or "new only" based on the information of the existing request flag and the new request flag (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 detailed topic difference for each topic (S46), and ends this process.

[0121] <Example of Topic Comparison List> Next, an example of the topic comparison list 230 will be described with reference to Fig. 19. Fig. 19 is a diagram showing the process of generating a topic comparison list. Here, (1) an example of an existing request and (2) an example of a new request extracted by the topic difference comparison unit 202 will be described, and then the topic comparison list 230 will be described.

[0122] (1) Example of Existing Requirements Extracted by the Topic Difference Comparison Unit 202 The topic difference comparison unit 202 extracts existing requirements from the request topic DB 221 shown in Fig. 15. The field configuration of the extracted existing requirements is the same as that of the request topic DB 221. For example, data with an existing project ID of P1 is extracted from the request topic DB 221.

[0123] (2) Example of a new request extracted by the topic difference comparison unit 202 The topic difference comparison unit 202 extracts a new request from the request topic DB 221 shown in Fig. 15. The field configuration of the extracted new request 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 Fig. 19. The topic comparison list 230 is made up of fields for the topic ID, whether it is included in an existing request or a new request, and the classification result.

[0125] The topic ID field stores the topic ID of each topic included in the new request and the existing request. The included in existing request field stores "YES" if the topic is included in the existing request, and "NO" if the topic is not included in the existing request. The included in new request field stores "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 classifying the topics based on the flag information.

[0126] For example, a topic with topic ID T1 is included in both existing requests and new requests, so the classification result is "both." Topics with topic IDs T1-1, T1-1-1, and T3 are included only in existing requests, so the classification result is "existing only." A topic with topic ID T2-1-1 is 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 area 44 for each topic in Fig. 16. This makes it easier for the user to check the detailed topics that exist in both the existing project and the new project, the detailed topics that exist only in the existing project, and the detailed topics that exist only in the new project.

[0128] In the requirement 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 requirement topic screen 30. Furthermore, for requirements automatically categorized by topic, the similarities and differences between the topics assigned to existing requirements are automatically analyzed, and the analysis results are displayed on the topic difference display screen 40. This makes it easy for users to repeat tasks such as adding their own views and performing further automatic analysis. Furthermore, even if the granularity of requirements varies from customer to customer, the requirement analysis system 1 extracts and classifies topics from the requirements, making it easier for users to understand the topics included in the requirements.

[0129] The more detailed a topic, the clearer its meaning becomes. However, this reduces the number of documents (learning data) containing the same topic. To address this issue, the requirement analysis system 1 according to one embodiment provides a hierarchical dictionary 222 in which classification candidates are defined in a hierarchy ranging from general information to detailed information. The learning data adjustment unit 203 uses, as the learning data 203a, topics for which the number of requests, including subtopics, is equal to or greater than a threshold, calculated based on the level of detail defined for each topic in the hierarchical dictionary 222. Therefore, when there is little learning data for detailed topics in lower hierarchies defined in the hierarchical dictionary 222, the learning data adjustment unit 203 can automatically adjust the number of detailed topics so that they are used to train classification candidates for topics in higher hierarchies. Furthermore, the learning data adjustment unit 203 does not classify topics with low classification reliability and a small amount of data. Therefore, the learning data adjustment unit 203 can create learning data 203a 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 to be trained by the classification model training unit 204 increases, improving the accuracy of the classification model 204a. The evaluation unit 205 classifies the topics included in a new request using the classification model 204a trained using the training data 203a with an adjusted number of topics. This also improves the accuracy with which the classification model 204a automatically classifies detailed topics.

[0131] The request topic screen 30 presents the user with detailed topics subordinate to the automatically categorized information. The topics assigned to the requirements are categorized by level of detail based on the hierarchical dictionary 222. By looking at the request topic screen 30, the user can easily understand the relationship between a certain topic and other topics. As described above, the requirements analysis system 1 automatically assigns topics to requirements for new projects and categorizes those topics. The user's only operation is to swap requirements within a topic or to change the topic assigned to a requirement.

[0132] The topic difference display screen 40 displays topic differences and detailed topic differences for each topic. From a document containing many requirements for each project, topics are extracted for each requirement in the existing project and the new project, and the screen shows how the topics are included in the requirements for the existing project and the new project. This makes it easier for the user to understand the classification results of the topics included in the requirements for the new project, enabling appropriate action for the new project. Furthermore, the comparison results of the topics in the existing and new requirements make it easier for the user to identify topics not included in the existing requirements and topics that are in the existing requirements but are unnecessary.

[0133] [Modification] In the embodiment described above, the project IDs of the existing project and the new project are input in the project ID input section 41 of the topic difference display screen 40 shown in Fig. 16, but other project IDs may also be input. For example, the requirements of multiple existing projects may be compared with those of a new project. Furthermore, assets that include the content of multiple projects as variability may also be compared.

[0134] Furthermore, the requirements analysis system 1 according to the present embodiment can use a classification model acquired from another requirements analysis system and perform additional learning on the classification model. In this configuration, the time required for the requirements analysis system 1 according to the present embodiment to adapt the classification model to the requirements of the target project can be significantly reduced compared to the time required to build the classification model from scratch.

[0135] The existing document and the new document may be used in the same project but may be different versions of the document. In this case, the existing document may be an example of a first version (old version) of the document, and the new document may be an example of a second version (new version) of the document that is newer than the first version.

[0136] In the above embodiment, an example in which the present invention is applied to projects and requirements in product development related to vehicle control has been described, but the present invention can also be applied to other technical fields. For example, the present invention may be applied to the development of financial, communications, and information systems, which require a huge amount of documentation for each project.

[0137] The present invention is not limited to the above-described embodiments, and various other applications and modifications are possible without departing from the spirit of the present invention as set forth in the claims. For example, the above-described embodiments provide detailed and specific descriptions of the system configuration in order to clearly explain the present invention, and are not necessarily limited to systems that include all of the described configurations. Furthermore, it is also possible to add, delete, or replace some of the configurations of the present embodiments with other configurations. Furthermore, the control lines and information lines shown are those considered necessary for the explanation, and do not necessarily represent all of the control lines and information lines in the product. In reality, it can be assumed that almost all of the configurations are interconnected.

[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...learning 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 requested 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 a plurality of the topics together with a level of detail representing a hierarchical structure of the topics; a learning data adjustment unit that extracts lower-level topics that belong to a lower hierarchy than the topic assigned to the first request based on the first requests and the topics assigned to the first requests obtained from the requested topic database and the hierarchical dictionary, and outputs the first requests to which the topic and at least one of the lower-level topics is assigned, the number of which is equal to or greater than a threshold, as learning data to be used for training a classification model that assigns topic candidates to one or more second requests described in a second document to be analyzed, and the number of topics is adjusted; a learning unit that uses the learning data as an input to create the classification model; and a topic candidate assignment unit that inputs the second requests to the classification model and assigns the topic candidates to the second requests. a topic assignment unit that assigns, to each of the topic candidates of the second request to which the topic candidates have been assigned, the subtopics of the topic candidates obtained from the hierarchical dictionary.

2. The requirements analysis system of claim 1, wherein the hierarchical dictionary stores the topics and the subtopics together with the level of detail assigned to each hierarchy, and the learning data adjustment unit extracts the subtopics that have been assigned a higher level of detail than the other subtopics.

3. The requirement analysis system according to claim 2, further comprising a display input unit that displays the topic candidates on a requirement topic screen according to the level of detail and in order of priority, and when a topic assignment operation is input to replace the topic candidate with another topic, outputs the second requirement in which the topic candidate has been replaced with the other topic to the topic candidate assignment unit.

4. The request analysis system of claim 3, wherein the topic candidate assignment unit again inputs the second request in which the topic candidate has been replaced with the other topic into the classification model, and assigns the topic candidate selected by the classification model to the second request; and when an instruction to complete the topic assignment operation is input, the display input unit saves the combination of the second request and the topic candidate assigned to the second request in the request topic database.

5. A requirement analysis system as described in claim 4, further comprising a topic difference comparison unit that compares the topic assigned to the first requirement with the topic assigned to the second requirement for each of the hierarchies to which the topics belong, and determines the topic differences.

6. The request analysis system according to claim 5, wherein the topic difference comparison unit classifies the topic assigned to the first request and the topic assigned to the second request into either the topic assigned to both the first request and the second request, the topic included only in the first request, or the topic included only in the second request, and obtains the topic difference as the result.

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

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

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

10. A requirement analysis method comprising the steps of: a learning data adjustment unit provided in a requirement analysis system extracting subtopics belonging to a lower hierarchy than the topic assigned to the first requirement based on one or more first requirements described in a first document and the topics assigned to the first requirements, which are obtained from a requirement topic database, and a hierarchical dictionary that records a plurality of the topics together with the levels of detail assigned to the topics, and outputting the first requirements to which at least one of the topics and the subtopics is assigned, the number of which is equal to or greater than a threshold, as learning data used for training a classification model that assigns topic candidates to one or more second requirements described in a second document to be analyzed, and for which the number of topics is adjusted; creating the classification model using the learning data as an input; inputting the second requirements into the classification model and assigning the topic candidates to the second requests; and assigning, for each of the topic candidates assigned to the second requests, the subtopics for the topic candidates obtained from the hierarchical dictionary.

Images