Requirement definition support system, requirement definition support method, and requirement definition support program

Abstract

To generate a low context requirement tree structure from description in a natural language.SOLUTION: A requirement definition support system 1 comprises a requirement refinement unit 14 that, when a sentence held in relation to requirement definition includes high-context elements, inputs the sentence to a large-scale language model 41 that automatically generates the requirement definition, and generates requirements comprising low-context elements. When the generated requirements include the high-context elements, the requirement refinement unit executes control of inputting the requirements to the large-scale language model 41 and performing further requirement generation.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to a technique for supporting requirement definition in system development, and more specifically, to a technique capable of generating a low-context requirement tree structure from a description in natural language.

Background Art

[0002] Requirement definition in system development is an important phase for forming a common understanding among project stakeholders and for avoiding risks and ensuring the quality of deliverables. Therefore, various conventional techniques have been proposed for the purpose of improving the efficiency and accuracy of such requirement definition.

[0003] For example, in Patent Document 1, a technique is disclosed for suppressing the disagreement in understanding among designers by eliminating the non-uniformity of terms, the non-expression of tacit knowledge, and the ambiguity of requirements, and for verifying the necessity and sufficiency of lower-level requirements with respect to higher-level requirements in order to prevent the occurrence of requirement contradictions and omissions. Also, in Patent Document 2, a technique is disclosed for more appropriately extracting parameters for evaluating non-functional requirements from documents related to the target system. In addition, in Patent Document 3, a technique is disclosed for automatically generating a program from information in natural language.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0005] As disclosed in the prior art, a technique for automatically generating source code by inputting a specification described in natural language into a generative model such as a neural network is known. Therefore, if requirement definitions can also be automatically generated, it would be beneficial from the perspectives of improving the efficiency and accuracy of the entire system development.

[0006] As a method for automatically generating such requirement definitions, for example, a method that uses a large language model among generative AIs can be assumed. In this method, the input text to the large language model and the output text from the large language model for the input text will be the components of the requirement definition.

[0007] However, texts that are the input and output targets of large language models are often high-context ones with the technical skills and experience of the person in charge as an implicit background. If such high-context texts are included in the requirement definition, the accuracy of the source code generated based on the requirement definition is likely to be unfavorable.

[0008] Also, texts described in natural language by humans often have a mixture of elements from multiple layers, such as high-context and low-context. Therefore, even if we try to combine and adopt the prior art shown in existing patents to generate low-context texts from high-context texts, some context may be missing in the process, and problems may occur where requirements that should be included in the requirement definition are left out.

[0009] Therefore, the present invention has been made in view of the above problems, and an object thereof is to provide a technique capable of generating a low-context requirement tree structure from a description in natural language.

Means for Solving the Problems

[0010] This application includes a plurality of means for solving the above problems. For example, they are as follows. To solve the above problems, a requirement definition support system according to an aspect of the present invention includes a requirement refinement unit that inputs the text that includes high-context elements regarding requirement definition into a large language model that automatically generates requirement definitions to generate requirements consisting of low-context elements, and when the requirements generated by the large language model include high-context elements, inputs the requirements into the large language model and executes control to perform further requirement generation.

[0011] Also, to solve the above problems, a requirement definition support method according to an aspect of the present invention includes a process in which an information processing device acquires a text regarding requirement definition, inputs the text into a large language model that automatically generates requirement definitions when the text includes high-context elements to generate requirements consisting of low-context elements, and executes control to input the requirements generated by the large language model into the large language model and perform further requirement generation when the requirements include high-context elements.

[0012] Also, to solve the above problems, a requirement definition support program according to an aspect of the present invention causes an information processing device to acquire a text regarding requirement definition, input the text into a large language model that automatically generates requirement definitions when the text includes high-context elements to generate requirements consisting of low-context elements, and execute control to input the requirements generated by the large language model into the large language model and perform further requirement generation when the requirements include high-context elements.

Advantages of the Invention

[0013] According to the present invention, it becomes possible to generate a low-context requirement tree structure from a description in natural language.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9

Figure 10A

Figure 10B

Figure 11

Figure 12

Figure 13

Figure 14

Mode for Carrying Out the Invention

[0015] In the following description, the communication device may be one or more communication interface devices. The one or more communication interface devices may be one or more homogeneous communication interface devices (e.g., one or more Network Interface Cards (NICs)), or two or more heterogeneous communication interface devices (e.g., a NIC and a Host Bus Adapter (HBA)).

[0016] Also, in the following description, the "main memory device" is one or more memory devices that are an example of one or more storage devices. At least one of the memory devices in the main memory device may be a volatile memory device or a non-volatile memory device.

[0017] Also, in the following description, the "auxiliary storage device" may be one or more persistent storage devices that are an example of one or more storage devices. The persistent storage device is typically a non-volatile storage device, and specifically may be, for example, a Hard Disk Drive (HDD), a Solid State Drive (SSD), or a Non-Volatile Memory Express (NVMe) drive.

[0018] Also, in the following description, the "processor" may be one or more processor devices. At least one processor device may typically be a microprocessor device such as a CPU (Central Processing Unit), but may also be other types of processor devices such as a GPU (Graphics Processing Unit). At least one processor device may be single-core or multi-core. At least one processor device may be a processor core. At least one processor device may also be a processor device in a broad sense such as a hardware circuit (e.g., FPGA (Field-Programmable Gate Array), CPLD (Complex Programmable Logic Device), or ASIC (Application Specific Integrated Circuit)) that performs part or all of the processing.

[0019] Also, in the following description, expressions such as "xxx table" and "xxx database" may be used to describe information from which an output can be obtained for an input, but the information may be data of any structure (e.g., structured data or unstructured data), or may also be a learning model such as a neural network, genetic algorithm, or random forest that generates an output for an input. Therefore, "xxx table" and "xxx database" can be referred to as "xxx information". Also, in the following description, the configuration of each database and table is an example, and one database or table may be divided into two or more databases or tables, or all or part of two or more databases or tables may be one database or table.

[0020] In the following description, the "program" may be used as the subject to explain the processing. However, since the program performs the defined processing by being executed by a processor, appropriately using a storage device and / or an interface device, etc., the subject of the processing may be the processor (or a device such as a controller having the processor). The program may be installed from a program source into a device such as a computer. The program source may be, for example, a program distribution server or a computer-readable (e.g., non-transitory) recording medium. Also, in the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0021] Also, in the following description, when explaining without distinguishing between elements of the same type, the common part of the reference signs is used, and when explaining while distinguishing between elements of the same type, reference signs or element identifiers may be used.

[0022] <Network Configuration of Requirement Definition Support System> Hereinafter, this embodiment will be described. FIG. 1 is a diagram showing an example of a network configuration constituting the requirement definition support system 1 of this embodiment. The requirement definition support system 1 is composed of a requirement definition support device 10 as its minimum configuration. However, it may include at least one of a user terminal 30 operated by a person in charge of requirement definition work and a service provision system 40 as shown in the illustrated network configuration.

[0023] The requirement definition support system 1 configured in this way is based on the technical background that, by improving the performance of generative AI, more specifically large language models, it has become possible to automatically generate source code from requirements. The requirement definition support system 1 in such an embodiment is a system that details requirements from a natural language description of high-context upper-level requirements and automatically generates functional requirements and non-functional requirements.

[0024] Among the network configurations shown in FIG. 1, the requirement definition support device 10 can specifically be assumed to be a server device. The requirement definition support device 10 is communicably connected to the user terminal 30 and the service providing system 40 via the network N. Note that the network N can be assumed to be the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), a mobile phone network, etc., but is not limited thereto.

[0025] The requirement definition support device 10 obtains and manages low-context requirements by attaching the text (requirement description written in natural language) input from the user terminal 30 to the large language model 41 of the service providing system 40 according to its context level. The low-context requirements obtained by the requirement definition support device 10 are stored in the requirement DB 20 and the requirement knowledge DB 21 described later. The requirements stored here are the targets for checking and taking measures regarding the presence or absence of the loop state of requirement generation and the lack of consistency between the generated requirements. Details of the specific configuration and functions of such a requirement definition support device 10 will be described later.

[0026] Also, the user terminal 30 is an operation terminal of a user who performs requirement definition work. This user can be assumed to be, for example, a development staff member in an SIer who conducts system development. The user terminal 30 assumes general terminal devices such as a PC (Personal Computer), a smartphone, and a tablet terminal. However, other various forms such as a thin client terminal and a console of a large computer can also be included in the applicable range.

[0027] The above-mentioned user operates this user terminal 30 to perform various requirement definition tasks, for example, writes a requirement description in natural language to create a text. Further, this text is uploaded to the requirement definition support device 10 by operating the user terminal 30, and the automatic generation of requirements by the large language model 41 is requested.

[0028] Further, the service providing system 40 is a server device having a large language model 41 as one of the generative AIs. In response to a request from the requirement definition support device 10, this service providing system 40 executes low-context requirement generation using a high-context sentence or requirement as input by the large language model 41. The generated low-context requirements are responded to the requirement definition support device 10 via the network N.

[0029] The above-mentioned interaction between the service providing system 40 and the requirement definition support device 10 is assumed to be implemented according to the protocol of, for example, an API (Application Programming Interface). Therefore, both devices have already implemented the functions and configurations for executing each process of requests and responses by the API.

[0030] Note that in this embodiment, an example in which this service providing system 40 generates requirements using the large language model 41 is adopted for explanation, but an operation mode in which the requirement definition support device 10 holds the large language model 41 and generates low-context requirements by itself may be adopted.

[0031] <Hardware Configuration of Requirement Definition Support Device> FIG. 2 is a diagram showing an example of the hardware configuration of an information processing device 100 corresponding to the requirement definition support device 10 in this embodiment. The information processing device 100 has a configuration in which an auxiliary storage device 101, a main storage device 102, a processor 104, an input device 105, an output device 106, and a communication device 107 are communicably connected by an appropriate interface such as an internal BUS.

[0032] Among these, the auxiliary storage device 101 is a storage means configured by non-volatile memory elements as described above, and in this embodiment, at least holds the databases of the requirement DB 20, the requirement knowledge DB 21, and the context level determination criterion DB 22. Specific examples of the data configurations of these databases will be described later.

[0033] In addition, the main memory device 102 serves as a storage means for holding a program 103 including an OS (Operating System) that controls the entire information processing device 100 and various applications. The processor 104 loads and executes the program 103 in the main memory device 102 to implement necessary functions.

[0034] The input device 105 is a means for receiving input operations by an administrator or the like of the requirement definition support device 10, and UI (User Interface) devices such as a keyboard, a mouse, and a microphone can be assumed. Further, the output device 106 is a means for outputting the result of information processing to an administrator or the like of the requirement definition support device 10, and UI (User Interface) devices such as a display, a speaker, a touch panel, and a printer can be assumed.

[0035] In addition, the communication device 107 is a communication means constituted by a communication chip corresponding to the protocol of the network N. The communication device 107 accesses the network N and is communicably connected to other devices (for example, the user terminal 30 and the service providing system 40) via this network N.

[0036] <Functional Configuration of Requirement Definition Support Device> Subsequently, based on FIG. 3, the functional configuration of the requirement definition support device 10 will be described. FIG. 3 is a diagram showing a functional configuration example of the requirement definition support device 10 in the present embodiment. The requirement definition support device 10 has functional units including a requirement type determination unit 11, a loop determination unit 12, a consistency check unit 13, a requirement refinement unit 14, a requirement output unit 15, and an editing processing unit 16.

[0037] These functional units are implemented by the processor 104 executing the program 103. In addition, in order for these functional units to function effectively and perform necessary processing, databases such as a requirement DB 20, a requirement knowledge DB 21, and a context level determination criterion DB 22 are also provided.

[0038] Among these, the requirement type determination unit 11 is a function that determines, for example, whether a sentence input from the user terminal 30 and held in the requirement DB 20 (or the main memory device 102), or a requirement generated by the large language model 41 from the sentence, corresponds to either a high-context or low-context requirement type.

[0039] A high-context description is a description that includes implicit knowledge, conditions, etc. not explicitly stated in the description, and it is difficult for those other than the person who made the description or those who deeply understand the person's thinking, experience, skills, etc. to understand it reliably. Therefore, when automatically generating requirements based on such high-context sentences, etc., there is a high risk of omission of necessary functional requirements and non-functional requirements.

[0040] On the other hand, a low-context description is composed of objective and uniquely understandable information and values, and no thinking such as inferring implicit knowledge is required like in high-context descriptions. Therefore, if requirements are automatically generated based on such low-context sentences, etc., it is less likely that necessary functional requirements and non-functional requirements will be omitted, and as a result, there is a high possibility of performing suitable requirement definition.

[0041] Therefore, in the requirement definition support apparatus 10 according to the present embodiment, after determining the context level of a sentence or requirement as an input to be given to the large language model 41, a process corresponding to the context level is selectively executed. Such control leads to an effect of improving the processing efficiency of the entire requirement definition. Specifically, for a sentence determined to be high-context, it is targeted for low-context requirement generation by the large language model 41, and for a sentence determined to be low-context, after undergoing a consistency check described later, it is to be stored in a database such as the requirement DB 20.

[0042] The requirement type determination unit 11 shall use the context level determination criterion DB22 as a criterion for making such context level determinations. Although details will be described later, the context level determination criterion DB22 is a database that defines the assumed criteria for each category (e.g., user, business, data, processing, availability, performance / extensibility, operation / maintenance, etc.) in both functional and non-functional requirements. The criteria defined in the context level determination criterion DB22 are the conditions under which the target sentence or requirement is determined to be a low context when they are met.

[0043] The requirement type determination unit 11 decomposes the sentence obtained from the user terminal 30 or the requirement generated by the large language model 41 from such a sentence into words by, for example, a morphological analysis engine (not shown) provided by itself or a morphological analysis service provided by an external system such as the service providing system 40, extracts the words of parts of speech such as nouns, verbs, and numerical values from these words, and collates them with the context level determination DB22.

[0044] The requirement type determination unit 11 determines whether the target sentence or the like is a requirement type including high context elements by verifying whether it conforms to the criteria defined in the context level determination DB22 in terms of the presence or absence and number of the above-mentioned words through such collation. The detailed procedures and content of such determinations will be described later.

[0045] Note that the determination method is not limited to only the form of making determinations based on rules as described above. For example, a determination model that has been pre-trained by deep learning may be used to implement the function of such determination. In this case, the determination model can be assumed to be a model that has undergone repeated deep learning using the context level determination cases made by those with rich knowledge and skills as teacher data. When using such a determination model in the context level determination process, the requirement type determination unit 11 shall obtain the context level determination result as the determination result by giving the above-mentioned sentence or requirement as the input of the determination model.

[0046] Subsequently, the loop determination unit 12 is a function that determines whether the requirement generation process in the large language model 41 corresponds to a situation where the same text or requirements are repeatedly processed multiple times, and determines whether such a situation is a meaningless requirement generation loop. As an example of such a loop, when the large language model 41 executes requirement generation with a certain text as input (intending to generate low-context requirements), if the requirements generated there are high-context requirements, the requirement type determination unit 11 will identify them as targets for re-generation of requirements. For example, a situation where such a situation is repeated two or more times is applicable.

[0047] This situation can be said to be a situation where the requirement generation by the large language model 41 is not linked to the generation of low-context requirements. The cause of such a situation is likely to be that there are some problems in the content of the text or requirements that are the starting point of requirement generation. Therefore, it is necessary to identify the text and requirements that have become the processing target or result during the process of the loop and promptly correct them manually. The main role of the loop determination unit 12 is to accurately identify the occurrence of a meaningless requirement generation loop, suppress unnecessary procedures, and realize efficient low-context requirement generation.

[0048] Therefore, the loop determination unit 12 searches the requirement DB 20 or the main memory device 102 for the same text or requirements that are the starting point of generation among the texts or requirements related to a certain development project. In the requirement DB 20, when texts and requirements are registered, it is assumed that the information is linked with the original texts and requirements, that is, the texts and requirements that are the input targets for the large language model 41, as upper-level requirements. In that case, when the above search is executed, a tree structure in which the hierarchy deepens and branches for each requirement generation among the texts and requirements held in the requirement DB 20, etc., that is, the hierarchical relationship becomes clear.

[0049] In this embodiment, the depth of such a hierarchical relationship is managed as follows: the starting sentence or requirement (existence) is regarded as the 0th level, the first requirement generation for such a sentence or the like is the 1st level, and the requirement generation further executed with the requirement generated by this first requirement generation as the input is the 2nd level. Also, regarding the requirement that is the processing target in the loop determination unit 12, it is assumed to be of the nth level.

[0050] The loop determination unit 12 treats the requirement A whose determination result by the requirement type determination unit 11 is the high context as being obtained by the requirement generation of the nth level in the hierarchical relationship of the above-described tree structure. Also, the loop determination unit 12 calculates the similarity between the requirement A obtained by this nth level requirement generation and the requirement B that is several levels higher than this nth level (for example, the requirement obtained by the (n - 2)th level requirement generation). The calculation of the similarity shall be, for example, by calculating the coincidence rate of the keywords included in the description of the requirement.

[0051] When the calculated similarity exceeds a certain standard, the loop determination unit 12 determines that requirements having the same content are repeatedly generated starting from the same sentence or requirement, that is, a loop in the requirement generation has occurred. Also, when such a loop in the requirement generation has occurred, the loop determination unit 12 receives, from the user terminal 30, a user input of the correct requirement content regarding the nth level requirement in which the loop has occurred and the (n - 2)th level sentence or requirement above it, and sets the requirement with the requirement content as the determination target in the requirement type determination unit 11.

[0052] Also, the consistency check unit 13 selects, from the requirement DB 20, other sentences or requirements that are the same as or similar to the requirement target and whose requirement content partially matches, regarding the sentence or requirement determined to be the low context requirement type as a result of the determination by the requirement type determination unit 11. The consistency check unit 13 outputs to the user terminal 30 that a contradiction to be resolved has occurred among the selected sentences or requirements. Regarding the output that such a contradiction has occurred, the consistency check unit 13 receives, from the user terminal 30, a user input for resolving the contradiction, and sets the requirement with the requirement content corresponding to the user input as the determination target by the requirement type determination unit 11.

[0053] Further, the requirement refinement unit 14 has a function of inputting the requirement or the sentence to the large language model 41 for those determined by the above-mentioned requirement type determination unit 11 to include high-context elements, that is, the requirements (or sentences) of high-context, and generating requirements consisting of low-context elements. In addition, when the requirements generated by the large language model 41 include high-context elements, the requirement refinement unit 14 inputs the requirements to the large language model 41 and executes control for further requirement generation.

[0054] Further, the requirement output unit 15 identifies a series of derivation relationships from the sentence (described in natural language) that is the starting point of requirement generation to each nth requirement based on the information of the sentences and requirements stored in the requirement DB 20. In addition, the requirement output unit 15 generates display data in which the objects corresponding to the target sentence and each requirement are arranged in a tree shape based on the identified series of derivation relationships, and outputs this to the user terminal 30. In addition, among the objects arranged in a tree shape in this way, the requirement output unit 15 performs display control with various highlighting displays such as attaching an icon or text indicating the occurrence of the contradiction, coloring the object, or expanding the line width to the object of the sentence or requirement that is the target of the contradiction identified by the consistency check unit 13.

[0055] Further, the editing processing unit 16 selects, from the requirement knowledge DB 21, the requirement history of past cases in which the sentence or requirement determined to be high-context by the requirement type determination unit 11 has the same or similar requirement target or requirement content as the sentence or requirement. The requirement knowledge DB 21 is a database that holds the requirement history regarding past cases.

[0056] Based on the selected requirement history, the editing processing unit 16 edits the sentence or requirement (determined as high-context). Although there is no limitation on the content of this editing, for example, it can be assumed that the requirement is for a past case where the development target is similar, and the value of the quantitative index of a specific non-functional requirement is set for the target item of the non-functional requirement in the sentence or requirement to be edited by the editing processing unit 16. Note that the requirement refinement unit 14 will input the sentence or requirement that has undergone the above editing into the large language model 41 to generate requirements.

[0057] <Database Configuration> Subsequently, the specific data configuration and the like of the database that the requirement definition support device 10 of this embodiment manages and uses in various processes will be described. FIG. 4 is a diagram showing a configuration example of the requirement DB 20 in this embodiment. The requirement DB 20 is a database in which each piece of information of the sentence (described in natural language) input from the user terminal 30 and the requirements (low-context or high-context requirements) automatically generated by inputting the sentence into the large language model 41 are stored as one record.

[0058] In the example shown in FIG. 4, it is an aggregate of records that associate each value of the requirement (description), its upper requirement ID (ID of the upper requirement in the hierarchical relationship), requirement type, and additional input with the requirement ID as the key.

[0059] Among these, the upper requirement ID is "Null" if there is no upper level as long as the sentence or requirement is the starting point of requirement generation by the large language model 41. For other requirements, the requirement ID of the requirement that was the input to the large language model 41 during generation is set. Also, the requirement type is the value of the determination result by the requirement type determination unit 11, and either the value of a high-context requirement or a low-context requirement is set. Further, for the additional input, "True" is set for the requirements determined by the loop determination unit 12 to have a loop occurred or the requirements determined by the consistency check unit 13 to have a consistency problem and that have received additional input such as correction by user input, and "False" is set for others.

[0060] FIG. 5 is a diagram showing a configuration example of the requirement knowledge DB 21 in the present embodiment. The requirement knowledge DB 21 is a database that stores and holds the generated sentences and requirements regarding various past development projects. Since the requirement knowledge DB 21 has the same data structure of records as the requirement DB 20, a detailed description thereof will be omitted.

[0061] FIG. 6A is a diagram showing a reference example of functional requirements in the context level determination criterion DB 22 of the present embodiment. The context level determination criterion DB 22 is a database that defines the criteria for determining whether the sentence or requirement to be processed is of the high-context or low-context type. In the criteria regarding the functional requirements shown in FIG. 6A, it is a collection of records in which each value of category, keyword, and criterion is associated.

[0062] Among these, the category indicates the genre of keywords that can be included as functional requirements. As an example, each category of user, business, data, and process is listed. Further, the keyword is defined as a list of terms belonging to the category and having a high frequency of use in the development work. In the case of FIG. 6A, the keywords associated with the category "user" are in the form associated with keywords such as administrator, user, and customer.

[0063] Also, the criterion describes the conditions necessary for low-context requirements in the set of the category and keyword. Regarding the category "user", the criterion is that only one (only) of the keywords "administrator, user, customer, ···" is clearly defined. In other words, it means that a functional requirement in which a plurality of keywords are used as "users" and their usage intentions are complicated is not recognized as low-context. Similarly, keywords and criteria are defined for each of the other categories.

[0064] Figure 6B is a diagram showing a reference example of non-functional requirements in the context level determination criteria DB22 of the present embodiment. In the criteria regarding the non-functional requirements shown in Figure 6A, it is a collection of records in which values of each of the category, non-functional requirements (keywords), quantitative indicators, and qualitative indicators are associated.

[0065] Among these, the category indicates the genre of keywords that can be included as non-functional requirements. As an example, each category of availability, performance / extensibility, and operation / maintenance is listed. Also, the non-functional requirements (keywords) are defined as a list of phrases belonging to the category and having a high frequency of use in development work. In the case of Figure 6B, the non-functional requirement (keyword) "operation rate" is associated with the category "availability" in a linked form.

[0066] Also, the quantitative indicator describes the value of the quantitative indicator required as a low-context requirement in the set of the category and non-functional requirements (keywords). For the keyword "operation rate" in the category "availability", it is conditional that "(numerical value)%" is described. In other words, it means that non-functional requirements for which the numerical value is not described regarding the "operation rate" corresponding to "availability" are not recognized as low-context.

[0067] Also, the qualitative indicator describes the value of the qualitative indicator required as a low-context requirement in the set of the category and non-functional requirements (keywords). For the non-functional requirement (keyword) "operation monitoring" in the category "operation / maintenance", it is conditional that "life / death monitoring, error monitoring, performance monitoring" is described. In other words, it means that non-functional requirements for which the monitoring content is not described regarding the "operation monitoring" corresponding to "operation / maintenance" are not recognized as low-context. Similarly for each of the other categories, non-functional requirements (keywords), quantitative indicators, and qualitative indicators are defined. <Requirement Definition Support Method: Main Flow>

[0068] Next, the processing flow in the requirement definition support method of this embodiment will be described. FIG. 7 is a diagram showing an example of a flow (part 1) in the requirement definition support method of this embodiment. Here, the overall processing flow in the requirement definition support apparatus 10 will be shown. In this case, it is assumed that the requirement definition support apparatus 10 has previously received a sentence including a requirement description from the user terminal 30 and holds it in the requirement DB 20.

[0069] The requirement definition support apparatus 10 in this embodiment executes each of the following processes S11 to S19 for each requirement held in the requirement DB 20 (S1S to S1E). Therefore, the requirement definition support apparatus 10 executes the process of determining the requirement type by the requirement type determination unit 11 for one requirement extracted from the requirement DB 20 (S11). The process of determining this requirement type will be described later with reference to FIG. 9.

[0070] Subsequently, the requirement definition support apparatus 10 determines whether the requirement to be processed is a high-context requirement based on the result of the requirement type determination (S12). As a result of the above determination, when the requirement is a low-context requirement rather than a high-context requirement (S12: No), the requirement definition support apparatus 10 executes the process of consistency check by the consistency check unit 13 (S13). The process of this consistency check will be described later with reference to FIGS. 10A and 10B.

[0071] As a result of the above consistency check, when there is a contradiction in the description of the requirement (S14: Yes), the requirement definition support apparatus 10 transmits a notification to the user terminal 30 requesting additional input by the user regarding the requirement (S15) and returns the process to S1. On the other hand, as a result of the above consistency check, when there is no contradiction in the description of the requirement (S14: No), the requirement definition support apparatus 10 ends this flow regarding the requirement and starts the processing flow for the unprocessed requirements.

[0072] On the other hand, as a result of the above requirement type determination, if the requirement is a high-context requirement (S12: Yes), the requirement definition support device 10 executes the loop determination process by the loop determination unit 12 (S16). The process of this loop determination will be described later with reference to FIG. 11. As a result of this loop determination, if a loop generation in requirement generation is identified (S17: Yes), the requirement definition support device 10 transmits a notification requesting additional input by the user regarding the requirement to the user terminal 30 (S18), and returns the process to S1.

[0073] On the other hand, as a result of the above loop determination, if a loop generation in requirement generation is not identified (S17: No), the requirement definition support device 10 executes the requirement refinement process by the requirement refinement unit 14 (S19), and returns the process to S1S.

[0074] In addition, as a result of step S17 in the above main flow, if a requirement generation loop has not occurred (S17: No), as shown in the flow of FIG. 8, the requirement definition support device 10 may search the requirement knowledge DB 21 for information on past cases (S17A), and then execute requirement refinement (S19). In this case, based on the requirement history that can be retrieved from the requirement knowledge DB 21, the editing processing unit 16 edits the sentence or requirement (determined as high-context in S12). As an example of the content of this editing, it can be assumed that, for requirements regarding past cases where the development target is similar, the value of the quantitative indicator of a specific non-functional requirement is set for the target item of the non-functional requirement in the sentence or requirement to be edited by the editing processing unit 16.

[0075] <Requirement Definition Support Method: Requirement Type Determination Flow> FIG. 9 is a diagram showing an example of a flow (Part 3) in the requirement definition support method of the present embodiment. Here, the detailed process of requirement type determination (S11) in the requirement type determination unit 11 will be described. In this case, the requirement type determination unit 11 of the requirement definition support device 10 selects a requirement to be determined (S20). This selection shall be read as the selection in step S1S of FIGS. 7 and 8.

[0076] Further, the requirement type determination unit 11 refers to the value in the "keyword" column of the functional requirement criterion 22A in the context level determination criterion DB 22, and determines whether the words included in the requirement selected as the next processing target are included in the value in the "keyword" column (S21). As a result of this determination, if the keyword is included in the words of the requirement (S21: Yes), the requirement type determination unit 11 determines whether each criterion of the functional requirement is satisfied (S22). In the example of FIG. 6A, it is determined whether each criterion of the categories "user", "business", "data", and "processing" is satisfied. For example, it is necessary that the condition that only one keyword out of the keywords "administrator, user, customer, ···" in the category "user" is included is satisfied, and only one keyword out of the keywords "*reception, *registration, *management, *reservation, ···" in the category "business" is included. The condition that only one keyword out of the keywords "*information, *data, *status status, *form, ···" in the category "data" is included is satisfied, and only one keyword out of the keywords "calculation, notification, cancellation, delivery, update, renewal, ···" in the category "processing" is included. The condition that it is included must be satisfied.

[0077] As a result of the above determination, if the situation does not satisfy all the criteria of the functional requirement (S22: No), the requirement type determination unit 11 determines that the requirement is a high-context requirement (S24), and ends this flow. On the other hand, as a result of the above determination, if all the criteria of the functional requirement are satisfied (S22: Yes), the requirement type determination unit 11 determines whether the requirement includes a non-functional requirement keyword (S23).

[0078] As a result of the above determination, if the non-functional requirement keyword is included (S23: Yes), the requirement type determination unit 11 determines that the requirement is a high-context requirement (S24), and ends this flow. On the other hand, as a result of the above determination, if the non-functional requirement keyword is not included (S23: No), the requirement type determination unit 11 determines that the requirement is a low-context requirement (S25), and ends this flow.

[0079] Also, if, as a result of the determination in step S21 described above, the target requirement does not include the keyword of the functional requirement (S21: No), the requirement type determination unit 11 determines whether it includes the keyword of the non-functional requirement (S26).

[0080] As a result of the above determination, if it does not include the keyword of the non-functional requirement either (S26: No), the requirement type determination unit 11 determines that the requirement is a high-context requirement (S24), and ends this flow. On the other hand, as a result of the above determination, if it includes the keyword of the non-functional requirement (S26: Yes), the requirement type determination unit 11 determines whether the requirement includes the value of the quantitative index or qualitative index regarding the non-functional requirement (S27). This determination is a process of searching for the numerical value in the requirement regarding each category of non-functional requirements (keywords) defined by the criteria of the non-functional requirements in the context level determination criteria DB22.

[0081] As a result of the above determination, if the value of the quantitative index or qualitative index regarding the non-functional requirement is not included (S27: No), the requirement type determination unit 11 determines that the requirement is a low-context requirement (S24), and ends this flow. On the other hand, as a result of the above determination, if the value of the quantitative index or qualitative index regarding the non-functional requirement is included (S27: Yes), the requirement type determination unit 11 determines that the requirement is a low-context requirement (S28), and ends this flow.

[0082] Note that the result of the above requirement type determination by the requirement type determination unit 11 will be set in the "requirement type" column of the corresponding record in the requirement DB20 and the requirement knowledge DB21 for the requirement to be determined.

[0083] <Requirement Definition Support Method: Consistency Check Flow> FIG. 10A is a diagram showing an example of a flow (Part 4) in the requirement definition support method of the present embodiment. Further, FIG. 10B is a diagram showing an example of a flow (Part 5) in the requirement definition support method of the present embodiment.

[0084] Based on the result of the requirement type determination (S11) by the requirement type determination unit 11, the consistency check unit 13 in this embodiment performs a consistency check on the sentence or requirement determined to be the requirement type of the local context. First, the consistency check regarding non-functional requirements will be described. In this case, the consistency check unit 13 executes the following steps S31 to S34 for each sentence or requirement of the local context that is the check target.

[0085] Therefore, the consistency check unit 13 selects, in the requirement DB 20, other sentences or requirements whose requirement targets match or are similar to the sentence or requirement of the local context that is the check target and whose requirement contents are partially the same (S31). The requirement target is, for example, the set of "categories" in the non-functional requirement standard 22B. Also, the requirement content is, for example, the set of "non-functional requirements (keywords)" and "quantitative indicators" or "qualitative indicators" for each category in the non-functional requirement standard 22B.

[0086] That is, "the requirement targets match or are similar and the requirement contents are partially the same" means that the set of categories matches or is similar (a certain ratio or more of the number of categories match), and the set of non-functional requirements (keywords) and quantitative indicators or qualitative indicators for each category are not completely the same but only partially different (for example, the non-functional requirement (keyword) used for the category "availability" is the same as "operation rate", but the values of the "quantitative indicators" of the operation rate are different from each other). That is, in step S31, similar requirements are selected where the approximate specifications are the same but only the values of the quantitative indicators or qualitative indicators indicating non-functional requirements are different.

[0087] Subsequently, the consistency check unit 13 extracts the quantitative indicators or qualitative indicators for each non-functional requirement for the requirement that is the check target and the requirement selected in S31 from the target records in the requirement DB 20 (S32).

[0088] Also, the consistency check unit 13 determines whether all of the quantitative or qualitative indicators extracted in S32 match between the requirements to be checked and the requirements selected in step S31 (S33). As a result of this determination, if all of the quantitative or qualitative indicators match (S33: Yes), the consistency check unit 13 returns the process to S30 to perform processing regarding the next requirements.

[0089] On the other hand, as a result of the above determination, if there is something that does not match in the quantitative or qualitative indicators (S33: No), the consistency check unit 13 determines that a contradiction has occurred between the requirements to be checked and the requirements selected in step S31 (S34), and returns the process to S30 to perform processing regarding the next requirements. Note that the presence or absence of such a contradiction is the determination result of step S14 in each of the flows of FIGS. 7 and 8, and is the notification target of the occurrence of the contradiction.

[0090] Subsequently, the consistency check regarding the functional requirements will be described. In this case, the consistency check unit 13 executes the following steps S40 to S45 for each sentence or requirement of the low context that is the check target.

[0091] Therefore, the consistency check unit 13 selects, in the requirement DB 20, other sentences or requirements in which the requirement target of the sentence or requirement of the low context to be checked matches or is similar and the requirement content partially matches. The requirement target is, for example, a set of "categories" in the function requirement standard 22A. Also, the requirement content is, for example, a set of "keywords" for each category in the function requirement standard 22A.

[0092] That is, the fact that the requirement target matches or is similar and the requirement content partially matches means that the set of categories matches or is similar (a certain ratio or more of the number of categories matches), and the set of keywords for each category is not completely the same but only partially different (for example, the keywords used for the categories "user" and "business" match, but the keywords regarding the category "data" are different), and such a situation is indicated.

[0093] Subsequently, the consistency check unit 13 extracts the keywords for each category from the target records in the requirement DB 20 for the requirement to be checked and the requirement selected in S41, and compares them (S42).

[0094] As a result of the above comparison, if the set of keywords extracted in S42 matches between the requirement to be checked and the requirement selected in step S41 (S43: Yes), the consistency check unit 13 returns the process to S40 to perform processing for the next requirement.

[0095] On the other hand, as a result of the above comparison, if the set of keywords extracted in S42 does not match between the requirement to be checked and the requirement selected in step S41 (S43: No), the consistency check unit 13 determines that a contradiction has occurred between the requirement to be checked and the requirement selected in step S41 (S44), and returns the process to S40 to perform processing for the next requirement. Note that the presence or absence of such a contradiction is the determination result of step S14 in each of the flows of FIGS. 7 and 8, and is the target of notification of the occurrence of the contradiction.

[0096] <Screen example: Consistency check result> FIG. 12 shows an example of a screen G10 when notifying a user terminal 30 of a contradiction occurrence in response to the result of the above consistency check. The screen G10 shown here includes at least a requirement display column G101 that shows the user the requirement content for the combination of requirements in which a contradiction has occurred due to the consistency check, a radio button G102 that asks the user whether the requirements of the combination are requirements described for the same specification, and an input column G103 that accepts from the user a description of the correct requirement content that aggregates the requirements of the above combination.

[0097] The user views screen G10 and recognizes that there are requirements with almost the same content but different numerical values for non-functional requirements, resulting in contradictions. If such requirements can be aggregated and expressed as one requirement, the user selects "Yes" with radio button G102. In that case, the user enters the correct requirement content in input field G103 and clicks the "Submit" button at the bottom of the screen to respond to requirement definition support device 10. Such an operation corresponds to "request additional input" in step S15 in the flows of FIGS. 7 and 8. That is, the requirement with the correct content is provided to requirement type determination unit 11 as the target for the next requirement type determination.

[0098] <Requirement Definition Support Method: Loop Determination Flow> FIG. 11 is a diagram showing an example of a flow (No. 6) in the requirement definition support method of the present embodiment. Here, the loop determination process in step S16 of the main flow will be described in detail. The significance of this loop determination process is to avoid a situation where the requirement generation process in large language model 41 is repeatedly and meaninglessly performed multiple times for the same text or requirements. For this purpose, it is a flow to identify and eliminate a loop of meaningless requirement generation. In the following description, an example of capturing an event where requirement generation starting from the same requirement or the like is repeated twice will be described, but it may also be assumed that an event of repeated generation three or more times is captured.

[0099] If the above-described event is left uncaptured, the requirement generation by large language model 41 will continue to consume time and computer resources without being linked to low-context requirement generation.

[0100] Therefore, loop determination unit 12 shall execute steps S51 to S55 in the flow of FIG. 11 for each high-context requirement. Here, prior to the start of this flow, loop determination unit 12 searches requirement DB 20 or main storage device 102 for the same text or requirement as the one that was the generation starting point among the texts or requirements related to a specific development project.

[0101] If this search is executed, the tree structure in which the hierarchy deepens and branches for each requirement generation among the sentences and requirements held in the requirement DB 20 or the like, that is, the hierarchical relationship becomes clear. In the present embodiment, the depth of such a hierarchical relationship is set to 0 for the sentence or requirement (existence) that is the generation starting point, the first requirement generation (by the large language model 41) for the sentence or the like is set to 1, and the requirement generation further executed with the requirement generated by this first requirement generation as the input is set to 2, and so on. Also, regarding the requirement that is the processing target in the loop determination unit 12, it is assumed to be of the n-th order.

[0102] Note that the loop determination unit 12 treats the requirement A for which the determination result by the requirement type determination unit 11 becomes the high context as being obtained by the n-th order requirement generation in the hierarchical relationship of the above-described tree structure. The loop determination unit 12 determines whether there is a requirement B that is higher than this n-th order by a plurality of orders (for example, a requirement obtained by the (n - 2)-th order requirement generation) than this n-th order requirement A obtained by this n-th order requirement generation (S51).

[0103] As a result of the above determination, when there is no higher requirement B (S51: No), the loop determination unit 12 ends this flow and returns to step S50 to start processing for the requirement of the next high context. On the other hand, as a result of the above determination, when there is a higher requirement B (S51: Yes), the loop determination unit 12 calculates the similarity between the above requirement A and requirement B (S52). The calculation of the similarity is, for example, to calculate the coincidence rate of keywords included in the description of the requirement.

[0104] Subsequently, the loop determination unit 12 determines whether the similarity calculated in step S52 exceeds a reference threshold value (S53). As a result of this determination, when the similarity does not exceed the threshold value (S53: No), the loop determination unit 12 ends this flow and returns to step S50 to start processing for the requirement of the next high context.

[0105] On the other hand, if the similarity exceeds the threshold as a result of the above determination (S53: Yes), the loop determination unit 12 determines that a loop has occurred during the requirement generation by the large language model 41, that is, the requirements of the same level of high context are continuously regenerated (S54), and ends this flow as the target of step S18 in the main flow.

[0106] Note that the loop determination unit 12 distributes the screen G15 shown in FIG. 13 to the user terminal 30 with respect to the n-th requirements in which such a loop has occurred and the (n-2)-th sentence or requirements above them. The user who views this screen G15 inputs the correct requirement content regarding the requirements of the high context where the loop occurs and responds to the requirement definition support device 10. The requirement definition support device 10 sets the requirements of the requirement content received from the user terminal 30 as the determination target in the requirement type determination unit 11.

[0107] <Screen example: Loop determination result> As shown in FIG. 13, the above-described screen G15 includes at least a requirement content column G151 showing the requirement contents of the high context requirements constituting the loop, and an additional information input column G152 for receiving input of additional information from the user regarding the requirements.

[0108] The user views the requirement content column G151 of the screen G15 and recognizes requirements with almost the same content but different generations that are repeatedly generated by the large language model 41 starting from the same sentence or requirements. For such requirements, the user fills in the correct requirements in the additional information input column G152. After that, the user clicks the "Submit" button at the bottom of the screen to respond to the requirement definition support device 10. Such an operation corresponds to "request additional input" in step S18 in the flows of FIGS. 7 and 8. That is, the requirements with the correct content are provided to the requirement type determination unit 11 as the target of the next requirement type determination.

[0109] <Screen example: Tree structure>

[0110] As a result of the series of processes described so far, in the requirement DB 20, starting from the sentences (requirements) described in natural language entered by the user, the n-th level requirements sequentially generated by the large language model 41 are accumulated while maintaining their hierarchical relationships as information. Therefore, based on the information of the sentences and requirements stored in the requirement DB 20, the requirement output unit 15 can identify a series of derivation relationships from the sentence (described in natural language) that is the starting point of requirement generation to each n-th level requirement.

[0111] In that case, based on the identified series of derivation relationships, the requirement output unit 15 generates display data in which the target sentence and the object G201 corresponding to each requirement are arranged in a tree shape as shown on the display screen G20 of FIG. 14. The requirement output unit 15 outputs this display data to the user terminal 30.

[0112] Note that among the objects G201 arranged in a tree shape in this way, the requirement output unit 15 performs display control with various highlighting displays such as attaching an icon G202 or text indicating the occurrence of the contradiction, or coloring the object G201 or expanding the line width, to the object of the sentence or requirement that is the target of the contradiction identified by the consistency check unit 13, or the object for which the user has input additional information for such requirements.

[0113] The user who has viewed the screen G20 with the above-described display control can visually recognize and easily understand the content and derivation relationships of each requirement constituting the requirement definition, and the existence of contradictions and the like among them in the target development project. This leads to the user being able to take appropriate and prompt actions regarding the problem areas, and it can be expected that the quality of the entire requirement definition will be improved and the work efficiency will be enhanced.

[0114] As described above, one embodiment of the present invention has been explained, but this is an example for explaining the present invention and is not intended to limit the scope of the present invention to this embodiment. The present invention can be implemented in various other forms.

[0115] Also, the above description can be summarized as follows. The following summary may include supplementary explanations or descriptions of variations of the above description.

[0116] In the requirement definition support system of the present embodiment, a requirement type determination unit that determines whether the text or the generated requirement corresponds to either a high-context or low-context requirement type based on criteria or determination models for each functional and non-functional requirement may be further provided, and it may be determined whether the text or the generated requirement is a requirement type that includes high-context elements.

[0117] According to this, the context characteristics of the text (described in natural language by a person) to be input to the large language model and the requirements generated based on the text are efficiently and accurately identified, and the efficiency of the entire subsequent flow can be improved. As a result, it becomes possible to more efficiently generate a requirement tree structure with good accuracy for low-context requirements from a description in natural language.

[0118] Also, in the requirement definition support system of the present embodiment, when the control of the further requirement generation reaches a plurality of times up to the nth time due to the requirement including high-context elements, a similarity between the requirement obtained in the nth requirement generation and the text or the requirement at a level higher than the nth time by more than one level is calculated, and a loop determination unit that determines the presence or absence of a loop in the requirement generation based on the similarity is further provided. As a result of the determination, when the loop in the requirement generation has occurred, for the nth requirement in which the loop has occurred and the text or the higher-level requirement, a user input of correct requirement content is accepted, and the requirement of the requirement content is set as the determination target of the requirement type.

[0119] According to this, it is possible to effectively avoid a situation where requirement generation by a large language model is repeatedly executed meaninglessly for the same text or requirements. Further, by obtaining intervention from the user for the processing of such text or requirements, the accuracy of the requirements to be generated later can be ensured. As a result, it becomes possible to more efficiently generate a more accurate low-context requirement tree structure from a description in natural language.

[0120] Further, in the requirement definition support system of the present embodiment, a requirement DB that stores the text and the requirements, and as a result of the determination regarding the requirement type, when the text or the requirements are of a low-context requirement type, other texts or requirements that have the same or similar requirement target as the text or the requirements that are the subject of the determination and whose requirement contents partially match are selected in the requirement DB, and a consistency check unit that outputs that a contradiction to be resolved has occurred between the text or the requirements and the other texts or requirements is further provided. Regarding the output indicating that the contradiction has occurred, it is also possible to accept a user input for resolving the contradiction and set the requirement with the requirement content corresponding to the user input as the subject of the determination of the requirement type.

[0121] According to this, even for low-context texts or requirements described regarding the same function, configuration, etc., it is possible to accurately identify specifications that damage the consistency in the whole case, such as different numerical values included therein, and accept a confirmation operation by the user. As a result, it becomes possible to more efficiently generate a low-context requirement tree structure with good accuracy from a description in natural language.

[0122] Also, in the requirement definition support system of the present embodiment, based on the text and the information of the requirements stored in the requirement DB (an example of requirement information), a series of derivation relationships from the text to each of the n-th level requirements are output in a display form in which objects corresponding to the text and each requirement are arranged in a tree shape. Among the objects arranged in the tree shape, display control indicating the occurrence of the contradiction may be performed on the object of the text or requirement that is the target of the contradiction.

[0123] According to this, starting from the text described in natural language by the user, the hierarchical structure of the requirements (non-functional / functional requirements) sequentially generated as necessary by the large language model can be visually clarified, and it becomes possible to prompt the user to understand the situation. Also, while performing such a display, intervention by the user regarding the problem part is accepted, and it becomes possible to establish a requirement definition without problems as a whole. As a result, it becomes possible to efficiently and accurately generate a low-context requirement tree structure with good accuracy and no inconsistencies from the description in natural language.

[0124] Also, in the requirement definition support system of the present embodiment, a requirement knowledge DB (an example of requirement knowledge information) that holds the requirement history regarding past cases, and when the requirement generated by the large language model includes high-context elements, the requirement history of past cases in which the text or the requirement and the requirement target or requirement content match or are similar is selected from the requirement knowledge DB, and an editing processing unit that edits the text or the requirement based on the requirement history is further provided. The requirement refinement unit may input the text or the requirement that has undergone the editing into the large language model to generate requirements.

[0125] According to this, it becomes possible to effectively utilize the knowledge about past similar cases and effectively improve the accuracy and efficiency of requirement generation. As a result, it becomes possible to more efficiently generate a low-context requirement tree structure from the description in natural language.

Explanation of Signs

[0126] N Network 1 Requirement Definition Support System 10 Requirement Definition Support Device 11 Requirement Type Judgment Unit 12 Loop Judgment Unit 13 Consistency Check Unit 14 Requirement Elaboration Unit 15 Requirement Output Unit 16 Editing Processing Unit 20 Requirement DB 21 Requirement Knowledge DB 22 Context Level Judgment Criterion DB 30 User Terminal 40 Service Provision System 41 Large Language Model 100 Information Processing Device 101 Auxiliary Storage Device 102 Main Memory Device 103 Program 104 Arithmetic Unit 105 Input Device 106 Output Device 107 Communication Device

Claims

1. A requirement refinement unit that, when the text to be retained regarding requirement definition includes high-context elements, inputs the text into a large language model for automatically generating requirement definitions to generate requirements consisting of low-context elements, and when the requirements generated by the large language model include high-context elements, inputs the requirements into the large language model and executes control for further generating requirements. A requirement definition support system characterized by this.

2. The requirement definition support system according to claim 1, further comprising a requirement type determination unit that determines whether the text or the generated requirements correspond to either high-context or low-context requirement types based on criteria or determination models for each functional and non-functional requirement, and determines whether the text or the generated requirements include high-context elements.

3. When the control for the further requirement generation due to the requirements including high-context elements reaches a plurality of times up to the nth time, a similarity between the requirements obtained in the nth requirement generation and the text or the requirements higher than the nth time by more than one time is calculated, and a loop determination unit that determines the presence or absence of loop generation of requirement generation based on the similarity is further provided. If, as a result of the determination, a loop of requirement generation has occurred, regarding the nth requirement where the loop has occurred and the text or the higher-level requirements, accepts a user input of correct requirement content, and makes the requirement of the requirement content the subject of determination of the requirement type. The requirement definition support system according to claim 2, characterized by this.

4. Requirement information for storing the text and the requirements, As a result of the determination regarding the requirement type, when the text or the requirements are of the low-context requirement type, selects, in the requirement information, another text or requirements whose requirement target is the same as or similar to the text or the requirements that are the subject of the determination and whose requirement content partially matches, and outputs that a contradiction to be resolved has occurred between the text or the requirements and the other text or requirements. A consistency check unit is further provided. Regarding the output indicating that the contradiction has occurred, accepts a user input for resolving the contradiction, and makes the requirement of the requirement content corresponding to the user input the subject of determination of the requirement type. Characterized by this. The requirement definition support system according to claim 3, characterized by comprising

5. further comprising a requirement output unit that outputs, in a display form in which objects corresponding to the text and each of the requirements are arranged in a tree shape, a series of derivation relationships from the text to each of the n-th requirements based on the text stored in the requirement information and the information of the requirements The requirement definition support system according to claim 4, characterized in that, among the objects arranged in the tree shape, display control indicating the occurrence of the contradiction is performed on the object of the text or requirement that is the target of the occurrence of the contradiction

6. requirement knowledge information that holds a requirement history regarding past cases, and when the requirement generated by the large language model includes elements of high context, selecting, in the requirement knowledge information, the requirement history of past cases in which the text or the requirement and the requirement target or requirement content match or are similar, and an editing processing unit that edits the text or the requirement based on the requirement history The requirement refinement unit inputs the text or the requirement after the editing into the large language model to generate requirements The requirement definition support system according to claim 1, characterized by

7. an information processing apparatus acquires a text related to requirement definition, and when the text includes elements of high context, inputs the text into a large language model that automatically generates requirement definitions to generate requirements composed of elements of low context, and when the requirement generated by the large language model includes elements of high context, inputs the requirement into the large language model and executes control for further requirement generation A requirement definition support method characterized by

8. In an information processing apparatus causes a text related to requirement definition to be acquired, and when the text includes elements of high context, inputs the text into a large language model that automatically generates requirement definitions to generate requirements composed of elements of low context, and when the requirement generated by the large language model includes elements of high context, inputs the requirement into the large language model and executes control for further requirement generation A requirement definition support program characterized by

Images