Requirement definition support system and requirement definition support method

Abstract

When a sentence retained regarding a requirement definition includes high-context elements, this requirement definition support system enters the sentence into a large-scale language model that automatically generates a requirement definition, and thereby causes the model to generate a requirement comprising low-context elements. If a generated requirement includes high-context elements, the requirement definition support system performs control to enter the requirement into the large-scale language model to further generate a requirement.

Description

Requirements definition support system and requirements definition support method

[0001] The present invention generally relates to a technology for supporting requirements definition in system development, and more particularly to a technology that enables the generation of a low-context requirements tree structure from a description in natural language.

[0002] Requirements definition in system development is an important phase for forming a common understanding among project stakeholders, avoiding risks, and ensuring the quality of deliverables. Therefore, various conventional technologies have been proposed to improve the efficiency and accuracy of requirements definition.

[0003] For example, Patent Document 1 discloses a technology that suppresses discrepancies in understanding among designers by eliminating inconsistencies in terminology, non-expression of tacit knowledge, and ambiguity in requirements, and enables verification of the necessity and sufficiency of lower-level requirements relative to higher-level requirements to prevent contradictions and oversights in requirements. Patent Document 2 discloses a technology that more appropriately extracts parameters for evaluating non-functional requirements from documents related to a target system. Patent Document 3 discloses a technology that automatically generates a program from information in natural language.

[0004] JP 2016-51234 A, WO 2015 / 145992, WO 2021 / 144904

[0005] As disclosed in the prior art, there is a known technology for automatically generating source code by inputting specifications written in natural language into a generative model such as a neural network. Therefore, if requirements definitions could also be automatically generated, it would be beneficial in terms of improving the efficiency and accuracy of the entire system development.

[0006] One possible method for automatically generating such requirements definitions is to use a large-scale language model, which is part of generative AI. In this method, the input sentences to the large-scale language model and the output sentences from the large-scale language model in response to the input sentences are used as components of the requirements definition.

[0007] However, the input and output texts of large-scale language models are often high-context texts that implicitly reflect the technical skills and experience of the person in charge. If such high-context texts are included in the requirements specification, there is a high possibility that the accuracy of the source code generated based on the requirements specification will be unsatisfactory.

[0008] Furthermore, text written by humans in natural language often contains a mixture of elements from multiple layers, namely high and low contexts. Therefore, even if an attempt is made to create low-context text from high-context text by combining and adopting conventional technologies shown in existing patents, some context may be lost in the process, and requirements that should be included in the requirements definition may also be omitted.

[0009] Therefore, the present invention has been made in consideration of the above-mentioned problems, and aims to provide a technology that enables generation of a low-context requirements tree structure from a description in natural language.

[0010] The present application includes multiple means for solving the above-mentioned problems, examples of which are as follows: To solve the above-mentioned problems, a requirements definition support system according to one aspect of the present invention comprises a requirements refining unit that, when a sentence held regarding a requirements definition contains a high-context element, inputs the sentence into a large-scale language model that automatically generates a requirements definition, and generates requirements made up of low-context elements, and, when a requirement generated by the large-scale language model contains a high-context element, inputs the requirement into the large-scale language model and executes control to generate further requirements.

[0011] In addition, in order to solve the above-mentioned problems, a requirements definition support method according to one embodiment of the present invention is characterized in that an information processing device acquires a sentence related to a requirements definition, and if the sentence contains a high-context element, inputs the sentence into a large-scale language model that automatically generates requirements definitions to generate requirements consisting of low-context elements, and if the requirements generated by the large-scale language model contain a high-context element, inputs the requirements into the large-scale language model and executes control to generate further requirements.

[0012] In addition, in order to solve the above-mentioned problems, a requirements definition support program according to one embodiment of the present invention is characterized in that it causes an information processing device to acquire a sentence related to a requirements definition, and if the sentence contains a high-context element, inputs the sentence into a large-scale language model that automatically generates requirements definitions to generate requirements consisting of low-context elements, and if the requirements generated by the large-scale language model contain a high-context element, inputs the requirements into the large-scale language model and executes control to generate further requirements.

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

[0014] 1 is a diagram showing an example of a network configuration in this embodiment. FIG. 2 is a diagram showing an example of a hardware configuration of a requirements definition support device in this embodiment. FIG. 3 is a diagram showing an example of a functional configuration of a requirements definition support system in this embodiment. FIG. 4 is a diagram showing an example of a requirements DB in this embodiment. FIG. 5 is a diagram showing an example of a requirements knowledge DB in this embodiment. FIG. 6 is a diagram showing an example of a standard for functional requirements in a context level judgment criteria DB in this embodiment. FIG. 7 is a diagram showing an example of a standard for non-functional requirements in a context level judgment criteria DB in this embodiment. FIG. 8 is a diagram showing an example of a flow (part 1) in a requirements definition support method in this embodiment. FIG. 9 is a diagram showing an example of a flow (part 2) in a requirements definition support method in this embodiment. FIG. 10 is a diagram showing an example of a flow (part 3) in a requirements definition support method in this embodiment. FIG. 11 is a diagram showing an example of a flow (part 4) in a requirements definition support method in this embodiment. FIG. 12 is a diagram showing an example of a flow (part 5) in a requirements definition support method in this embodiment. FIG. 13 is a diagram showing an example of a flow (part 6) in a requirements definition support method in this embodiment. FIG. 14 is a diagram showing an example of a screen in this embodiment. FIG. 15 is a diagram showing an example of a screen in this embodiment. FIG. 16 is a diagram showing an example of a screen in this embodiment.

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

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

[0017] In the following description, an "auxiliary storage device" may be one or more persistent storage devices, which are an example of one or more storage devices. The persistent storage device may typically be a non-volatile storage device, specifically, for example, a hard disk drive (HDD), a solid state drive (SSD), or a non-volatile memory express (NVMe) drive.

[0018] Furthermore, in the following description, a "processor" may refer to one or more processor devices. The 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). The at least one processor device may be a single-core or multi-core. The at least one processor device may also be a processor core. The at least one processor device may also be a processor device in a broader sense, such as a hardware circuit that performs part or all of the processing (for example, an FPGA (Field-Programmable Gate Array), a CPLD (Complex Programmable Logic Device), or an ASIC (Application Specific Integrated Circuit)).

[0019] In the following description, information that provides an output in response to an input may be described using expressions such as "xxx table" or "xxx database." However, this information may be data of any structure (for example, structured data or unstructured data), or may be a learning model such as a neural network, genetic algorithm, or random forest that generates an output in response to an input. Therefore, "xxx table" or "xxx database" can be referred to as "xxx information." In the following description, the structure of each database or 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 a single database or table.

[0020] In the following description, processing may be described using a "program" as the subject. However, since a program is executed by a processor to perform a predetermined process using a storage device and / or an interface device, etc., as appropriate, the subject of the process may also be the processor (or a device such as a controller having the processor). A program may be installed in a device such as a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable (e.g., non-transitory) recording medium. 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] In addition, in the following description, when describing elements of the same type without distinguishing between them, common parts of the reference symbols may be used, and when describing elements of the same type with distinction between them, reference symbols or element identifiers may be used.

[0022] <Network Configuration of Requirements Definition Support System> This embodiment will be described below. Fig. 1 is a diagram showing an example of a network configuration constituting a requirements definition support system 1 of this embodiment. The requirements definition support system 1 is composed of a requirements definition support device 10 as its minimum configuration. However, as in the network configuration shown in the figure, the system may also include at least one of a user terminal 30 operated by a person in charge of requirements definition work and a service providing system 40.

[0023] The requirements definition support system 1 configured in this way takes into account the technological background in which automatic generation of source code from requirements has become possible due to improvements in the performance of generative AI, more specifically, large-scale language models. The requirements definition support system 1 in this embodiment is a system that refines requirements from natural language descriptions of high-context, upper-level requirements and automatically generates functional requirements and non-functional requirements.

[0024] 1, the requirements definition support device 10 may be a server device. The requirements definition support device 10 is communicably connected to a user terminal 30 and a service providing system 40 via a network N. The network N may be the Internet, a local area network (LAN), a wide area network (WAN), a mobile phone network, or the like, but is not limited to these.

[0025] The requirements definition support device 10 acquires and manages low-context requirements by assigning sentences (requirements descriptions written in natural language) input from a user terminal 30 to a large-scale language model 41 of a service providing system 40 according to their context level. The low-context requirements acquired by the requirements definition support device 10 are stored in a requirements DB 20 and a requirements knowledge DB 21, which will be described later. The requirements stored here are subject to checks and measures for the presence or absence of a requirements generation loop, lack of consistency between generated requirements, etc. The specific configuration and functions of the requirements definition support device 10 will be described in detail later.

[0026] The user terminal 30 is an operation terminal of a user who performs requirements definition work. This user can be, for example, a development staff member at a system integrator (SIer) that develops systems. The user terminal 30 is assumed to be a general terminal device such as a PC (Personal Computer), a smartphone, or a tablet terminal. However, various other forms, such as a thin client terminal or a console of a large computer, can also be included in the scope of application.

[0027] The user operates the user terminal 30 to perform various tasks for requirements definition, for example, to write a sentence by describing requirements in a natural language, and then operates the user terminal 30 to upload the sentence to the requirements definition support device 10 and request automatic generation of requirements using the large-scale language model 41.

[0028] The service providing system 40 is a server device having a large-scale language model 41 as one of the generation AIs. In response to a request from the requirements definition support device 10, the service providing system 40 receives high-context sentences and requirements as input and generates low-context requirements using the large-scale language model 41. The generated low-context requirements are returned to the requirements definition support device 10 via the network N.

[0029] The above-mentioned exchange between the service providing system 40 and the requirements definition support device 10 is performed according to, for example, an API (Application Programming Interface) protocol. For this purpose, both devices are pre-implemented with functions and configurations for executing each process of requests and responses by the API.

[0030] In this embodiment, an example will be explained in which the service providing system 40 generates requirements using a large-scale language model 41, but an operating form may also be adopted in which the requirements definition support device 10 holds the large-scale language model 41 and generates low-context requirements by itself.

[0031] 2 is a diagram showing an example of the hardware configuration of an information processing device 100 corresponding to the requirements definition support device 10 in this embodiment. The information processing device 100 is configured such that 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 communicatively connected by an appropriate interface such as an internal BUS.

[0032] Of these, the auxiliary storage device 101 is a storage means configured with non-volatile storage elements, as already mentioned, and in this embodiment, holds at least the databases of a requirements DB 20, a requirements knowledge DB 21, and a context level judgment criteria DB 22. Specific examples of the data configurations of these databases will be described later.

[0033] The main memory device 102 also serves as a storage means for storing programs 103, including an operating system (OS) that controls the entire information processing device 100 and various applications. The processor 104 loads and executes the programs 103 in the main memory device 102, thereby implementing required functions.

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

[0035] The communication device 107 is a communication means configured by a communication chip compatible with the protocol of the network N. The communication device 107 accesses the network N and is communicatively connected to other devices (e.g., the user terminal 30 and the service providing system 40) via this network N.

[0036] <Functional Configuration of the Requirements Definition Support Device> Next, the functional configuration of the requirements definition support device 10 will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the functional configuration of the requirements definition support device 10 in this embodiment. The requirements definition support device 10 has the following functional units: a requirement type determination unit 11, a loop determination unit 12, a consistency check unit 13, a requirement detailing unit 14, a requirement output unit 15, and an edit processing unit 16.

[0037] Each of these functional units is implemented by the processor 104 executing the program 103. In addition, in order for each of these functional units to function effectively and perform the necessary processing, the system also has the databases of a requirements DB 20, a requirements knowledge DB 21, and a context level determination criteria DB 22.

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

[0039] High-context descriptions contain tacit knowledge and conditions that are not explicitly stated in the description, making them difficult to understand by anyone other than the person who wrote the description or someone who has a deep understanding of that person's thinking, experience, skills, etc. Therefore, when requirements are automatically generated based on such high-context text, there is a high risk that necessary functional and non-functional requirements will be overlooked.

[0040] On the other hand, low-context descriptions are composed of objective, uniquely understandable information and values, and do not require the kind of thinking that requires inferring tacit knowledge, as is the case with high-context descriptions. Therefore, if requirements are automatically generated based on such low-context text, it is unlikely that necessary functional or non-functional requirements will be overlooked, and as a result, there is a high possibility that favorable requirements definition will be achieved.

[0041] Therefore, the requirements definition support device 10 in this embodiment determines the context level of sentences and requirements as input to the large-scale language model 41, and then selectively executes processing according to the context level. Such control leads to the effect of improving the overall processing efficiency of requirements definition. Specifically, sentences, etc. determined to be high context are subject to low context requirement generation by the large-scale language model 41, and sentences, etc. determined to be low context are subject to a consistency check, which will be described later, and are then subject to storage in a database such as the requirements DB 20.

[0042] The requirement type determination unit 11 uses the context level determination criteria DB 22 as a criterion for determining the context level. As will be described in detail later, the context level determination criteria DB 22 is a database that specifies the criteria expected for each category of functional and non-functional requirements (e.g., user, business, data, processing, availability, performance / scalability, operation / maintenance, etc.). The criteria specified in the context level determination criteria DB 22, when satisfied, are conditions for determining that a target document or requirement is low-context.

[0043] The requirement type determination unit 11 breaks down sentences obtained from the user terminal 30, or requirements generated from such sentences by the large-scale language model 41, into words and phrases using, for example, its own morphological analysis engine (not shown) or a morphological analysis service provided by an external system such as the service providing system 40, and extracts words of parts of speech such as nouns, verbs, and numbers from these words and phrases, and compares them with the context level determination DB 22.

[0044] The requirement type determination unit 11 determines whether the target text, etc. is of a requirement type that includes high-context elements by verifying whether the text, etc. conforms to the criteria defined in the context level determination DB 22 in terms of the presence or absence and number of the above-mentioned words and phrases through this matching. The detailed procedure and content of this determination will be described later.

[0045] Note that the judgment method is not limited to the rule-based judgment described above, and the judgment function may be implemented using, for example, a judgment model that has been trained in advance using deep learning. In this case, the judgment model may be a model that has undergone deep learning using context-level judgment cases performed by people with extensive knowledge and skills as training data. When such a judgment model is used for context-level judgment processing, the requirement type judgment unit 11 provides the above-mentioned sentences and requirements as input to the judgment model, and obtains a context-level judgment result as the judgment result.

[0046] Next, the loop determination unit 12 has a function of dealing with a situation in which the requirements generation process in the large-scale language model 41 is repeated multiple times for the same sentence or requirement, and determining whether the situation is a meaningless requirements generation loop. An example of such a loop is when the large-scale language model 41 executes requirements generation using a certain sentence as input (intending to generate low-context requirements), and if the generated requirements are high-context requirements, the requirements type determination unit 11 identifies them as targets for further requirements generation, and this situation is repeated, for example, two or more times.

[0047] This situation can be said to be one in which requirements generation by the large-scale language model 41 is not linked to low-context requirements generation. The cause of this situation is likely to be some kind of problem with the sentence or requirement content that was the starting point for requirements generation. Therefore, it becomes necessary to identify the sentence or requirement that was the processing target or processing result during the loop and promptly correct it manually. The main role of the loop determination unit 12 is to accurately identify the occurrence of meaningless requirements generation loops, suppress unnecessary procedures, and realize efficient low-context requirements generation.

[0048] Therefore, the loop determination unit 12 searches the requirements DB 20 or the main storage device 102 for sentences or requirements related to a certain development project that are identical in origin to the sentence or requirement that was used as the generation source. Note that when a sentence or requirement is registered in the requirements DB 20, the original sentence or requirement that was input to the large-scale language model 41 is treated as a higher-level requirement, and the information is linked to it. In this case, performing the above-mentioned search reveals a tree structure, i.e., a hierarchical relationship, between each sentence or requirement held in the requirements DB 20 or the like, where the hierarchy deepens and can branch with each requirement generation.

[0049] In this embodiment, the depth of such hierarchical relationships is managed as follows: the (existence of) a sentence or requirement that is the starting point for generation is set as the 0th order, the first requirement generation for that sentence, etc. is set as the 1st order, and the requirement generation that is further executed using the requirements generated in this 1st order requirement generation as input is set as the 2nd order. Also, the requirements that are the subject of processing in the loop determination unit 12 are set as the nth order.

[0050] The loop determination unit 12 treats requirement A, whose determination result by the requirement type determination unit 11 is high context, as being obtained in the nth-order requirement generation in the hierarchical relationship of the tree structure described above. The loop determination unit 12 also calculates the similarity between requirement A obtained in the nth-order requirement generation and requirement B, which is several orders higher than the nth-order requirement generation (for example, a requirement obtained in the n-2th-order requirement generation). The calculation of the similarity is performed, for example, by calculating the matching rate of keywords included in the description of the requirement.

[0051] If the calculated similarity exceeds a certain standard, the loop determination unit 12 determines that requirements with similar content have been repeatedly generated starting from the same sentence or requirement, that is, that a requirement generation loop has occurred. Furthermore, if a requirement generation loop has occurred in this way, the loop determination unit 12 accepts user input of correct requirement content from the user terminal 30 for the nth-order requirement in which the loop has occurred and the n-2th-order sentence or requirement above it, and sets the requirement with the requirement content as the target for determination by the requirement type determination unit 11.

[0052] Furthermore, for a sentence or requirement determined to be a low-context requirement type as a result of the determination by the requirement type determination unit 11, the consistency check unit 13 selects other sentences or requirements in the requirement DB 20 that have the same or similar requirement target and partially identical requirement content as the sentence or requirement. The consistency check unit 13 outputs to the user terminal 30 a message that a contradiction to be resolved has occurred between the selected sentences or requirements. In response to the output that such a contradiction has occurred, the consistency check unit 13 accepts user input from the user terminal 30 to resolve the contradiction, and sets the requirement with the requirement content corresponding to the user input as the target of determination by the requirement type determination unit 11.

[0053] Furthermore, the requirement detailing unit 14 has a function of inputting a requirement (or sentence) that contains a high-context element, i.e., that is determined to be a high-context requirement (or sentence) by the requirement type determination unit 11, into the large-scale language model 41 and generating a requirement made up of low-context elements. Note that, if a requirement generated by the large-scale language model 41 contains a high-context element, the requirement detailing unit 14 inputs the requirement into the large-scale language model 41 and executes control to generate further requirements.

[0054] Furthermore, the requirements output unit 15 identifies a series of derivation relationships from the sentence (written in natural language) that was the starting point for generating the requirements to each of the n-th order requirements, based on the information on the sentences and requirements stored in the requirements DB 20. Furthermore, the requirements output unit 15 generates display data in which objects corresponding to the target sentences and each requirement are arranged in a tree-like manner, based on the identified series of derivation relationships, and outputs this to the user terminal 30. Furthermore, the requirements output unit 15 performs display control on the sentences or requirement objects identified by the consistency check unit 13 as the subject of a contradiction, among the objects arranged in this tree-like manner, by adding an icon or text indicating the occurrence of the contradiction, or by various highlighting displays such as coloring the object or widening the line width.

[0055] Furthermore, for a sentence or a requirement determined to be high-context by the requirement type determination unit 11, the editing processing unit 16 selects, from the requirements knowledge DB 21, the requirement history of past cases whose requirement targets or requirement contents match or are similar to the sentence or requirement. The requirements knowledge DB 21 is a database that holds the requirement history of past cases.

[0056] The editing processing unit 16 edits the sentences or requirements (determined to be high-context) based on the selected requirements history. Although the content of this editing is not limited, one example is to set the value of a quantitative indicator of a specific non-functional requirement related to a past project with a similar development target to the target item of the non-functional requirement in the sentences or requirements edited by the editing processing unit 16. The requirements detailing unit 14 inputs the sentences or requirements that have undergone the above-mentioned editing into the large-scale language model 41 to generate requirements.

[0057] <Database Configuration> Next, a specific data configuration of the database managed by the requirements definition support device 10 of this embodiment and used in various processes will be described. Fig. 4 is a diagram showing an example of the configuration of the requirements DB 20 in this embodiment. The requirements DB 20 is a database in which each piece of information, such as sentences (written in natural language) input from the user terminal 30 and requirements (low-context or high-context requirements) automatically generated by inputting the sentences into the large-scale language model 41, is accumulated as a single record.

[0058] In the example shown in Figure 4, the requirement ID is used as a key to create a collection of records that link together the following values: requirement (description), its higher-level requirement ID (ID of the higher-level requirement in the hierarchical relationship), requirement type, and additional input.

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

[0060] 5 is a diagram showing an example of the configuration of the requirements knowledge DB 21 in this embodiment. The requirements knowledge DB 21 is a database that stores and holds documents and requirements that have been stored and generated for various past development projects. The requirements knowledge DB 21 has the same data structure of records as the requirements DB 20, so a detailed description will be omitted.

[0061] 6A is a diagram showing an example of functional requirement criteria in the context level determination criteria DB 22 of this embodiment. The context level determination criteria DB 22 is a database that specifies criteria for determining whether a document or requirement to be processed is a high-context or low-context type. The functional requirement criteria shown in FIG. 6A are a collection of records that link categories, keywords, and criterion values.

[0062] Among these, the category indicates the genre of keywords that may be included as functional requirements, and examples include the categories of user, business, data, and processing. The keywords are defined as a list of words that belong to the category and are frequently used in development work. In the case of Figure 6A, keywords related to the category "user" are linked to keywords such as administrator, user, and customer.

[0063] The criteria also describe the necessary conditions for a given category and keyword set as low-context requirements, and for the category "user," the criteria is that one (and only one) of the keywords "administrator, user, customer, ..." is clearly defined. In other words, functional requirements that use multiple keywords for "user" and whose intended use is confusing are not recognized as low-context. Keywords and criteria are similarly specified for each of the other categories.

[0064] 6B is a diagram showing an example of criteria for non-functional requirements in the context level criteria DB 22 of this embodiment. The criteria for non-functional requirements shown in Fig. 6A are a collection of records in which the values ​​of categories, non-functional requirements (keywords), quantitative indicators, and qualitative indicators are linked.

[0065] Among these, the category indicates the genre of keywords that may be included as non-functional requirements, and examples include the categories of availability, performance / scalability, and operation / maintenance. Furthermore, the non-functional requirements (keywords) are defined as a list of words that belong to the category and are frequently used in development work. In the case of Figure 6B, "uptime" is linked to the non-functional requirement (keyword) related to the category "availability."

[0066] Furthermore, the condition for quantitative indicators is that the values ​​of the quantitative indicators required as low-context requirements are described in the set of category and non-functional requirements (keywords), and that "(numerical value) %" is described for the keyword "uptime" in the category "availability." In other words, non-functional requirements that do not describe a numerical value for "uptime" corresponding to "availability" are not recognized as low-context.

[0067] Furthermore, the qualitative indicators describe the values ​​of the qualitative indicators required as low-context requirements for the set of category and non-functional requirements (keywords), and the condition is that "alive monitoring, error monitoring, performance monitoring" are described for the non-functional requirement (keyword) "operational monitoring" in the category "operation and maintenance." In other words, this means that non-functional requirements that do not describe the monitoring content for "operational monitoring" corresponding to "operation and maintenance" are not recognized as low-context. Non-functional requirements (keywords) and quantitative and qualitative indicators are similarly specified for each of the other categories. <Requirements definition support method: Main flow>

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

[0069] The requirements definition support device 10 in this embodiment executes the following steps S11 to S19 (S1S to S1E) for each requirement held in the requirements DB 20. The requirements definition support device 10 then executes a requirement type determination process by the requirements type determination unit 11 for one requirement extracted from the requirements DB 20 (S11). This requirement type determination process will be described later with reference to FIG. 9.

[0070] Next, the requirements 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). If the result of the above determination is that the requirement is a low-context requirement rather than a high-context requirement (S12: No), the requirements definition support apparatus 10 executes a consistency check process by the consistency check unit 13 (S13). This consistency check process will be described later with reference to FIGS. 10A and 10B.

[0071] If the result of the consistency check indicates that there is a contradiction in the description of the requirement (S14: Yes), the requirements definition support device 10 sends a notification to the user terminal 30 requesting additional input from the user regarding the requirement (S15), and returns the process to S1. On the other hand, if the result of the consistency check indicates that there is no contradiction in the description of the requirement (S14: No), the requirements definition support device 10 ends this flow for the requirement and starts the processing flow for unprocessed requirements.

[0072] On the other hand, if the result of the requirement type determination indicates that the requirement is a high-context requirement (S12: Yes), the requirements definition support apparatus 10 executes a loop determination process by the loop determination unit 12 (S16). This loop determination process will be described later with reference to Fig. 11. If the result of this loop determination indicates that a loop has occurred in the requirements generation (S17: Yes), the requirements definition support apparatus 10 transmits a notification to the user terminal 30 requesting additional input by the user regarding the requirement (S18), and returns the process to S1.

[0073] On the other hand, if the result of the above loop judgment does not identify the occurrence of a loop in requirement generation (S17: No), the requirements definition support device 10 executes the requirements detailing process by the requirements detailing unit 14 (S19) and returns the process to S1S.

[0074] If a requirements generation loop has not occurred as a result of step S17 in the main flow (S17: No), the requirements definition support device 10 may search for information about past cases in the requirements knowledge DB 21 (S17A) and then execute requirement refinement (S19), as shown in the flow of FIG. 8 . In this case, the editing processing unit 16 edits the text or requirements (determined to be high-context in S12) based on the requirements history searched for in the requirements knowledge DB 21. One example of the content of this editing may be setting the value of a quantitative indicator of a specific non-functional requirement related to a past case with a similar development target to the target item of the non-functional requirement in the text or requirement edited by the editing processing unit 16.

[0075] <Requirements Definition Support Method: Requirement Type Determination Flow> Figure 9 is a diagram showing an example flow (part 3) of the requirements definition support method of this embodiment. Here, the details of the requirement type determination process (S11) by the requirements type determination unit 11 will be described. In this case, the requirements type determination unit 11 of the requirements definition support device 10 selects a requirement to be determined (S20). This selection should be interpreted as the selection in step S1S in Figures 7 and 8.

[0076] The requirement type determination unit 11 also refers to the value in the "Keyword" column of the functional requirement criteria 22A in the context level determination criteria DB 22, and determines whether the value in the "Keyword" column contains a word or phrase contained in the requirement selected as the current processing target (S21). If the result of this determination shows that the keyword is included in the word or phrase of the requirement (S21: Yes), the requirement type determination unit 11 determines whether each of the criteria for the functional requirement is met (S22). In the example of Figure 6A, it would determine whether the criteria for each of the categories "User," "Business," "Data," and "Processing" are met. For example, the condition that only one of the keywords "administrator, user, customer, ..." in the category "user" is included must be satisfied; the condition that only one of the keywords "*reception, *registration, *management, *reservation, ..." in the category "business" is included must be satisfied; the condition that only one of the keywords "*information, *data, *status, *report, ..." in the category "data" is included must be satisfied; and the condition that only one of the keywords "calculation, notification, cancellation, distribution, update, renewal, ..." in the category "processing" is included must be satisfied.

[0077] If the result of the above determination is that the requirement does not meet all the criteria for functional requirements (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, if the result of the above determination is that the requirement meets all the criteria for functional requirements (S22: Yes), the requirement type determination unit 11 determines whether the requirement includes keywords for non-functional requirements (S23).

[0078] If the result of the above determination is that the requirement contains a non-functional requirement keyword (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, if the result of the above determination is that the requirement does not contain a non-functional requirement keyword (S23: No), the requirement type determination unit 11 determines that the requirement is a low-context requirement (S25) and ends this flow.

[0079] Furthermore, if the result of the determination in the above-mentioned step S21 is that the target requirement does not include keywords for functional requirements (S21: No), the requirement type determination unit 11 determines whether the target requirement includes keywords for non-functional requirements (S26).

[0080] If the result of the above determination is that the requirement does not contain any non-functional requirement keywords (S26: No), the requirements type determination unit 11 determines that the requirement is a high-context requirement (S24) and ends this flow. On the other hand, if the result of the above determination is that the requirement contains non-functional requirement keywords (S26: Yes), the requirements type determination unit 11 determines whether the requirement contains quantitative or qualitative indicator values ​​related to non-functional requirements (S27). This determination is a process of searching for numerical values ​​in the requirement for non-functional requirements (keywords) of each category defined in the non-functional requirement criteria in the context level determination criteria DB 22.

[0081] If the result of the above determination is that the value of a quantitative indicator or a qualitative indicator related to a 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, if the result of the above determination is that the value of a quantitative indicator or a qualitative indicator related to a 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] The result of the requirement type determination by the requirement type determination unit 11 is set in the "requirement type" column of the corresponding record in the requirement DB 20 and the requirement knowledge DB 21 for the requirement that was determined.

[0083] <Requirements Definition Support Method: Consistency Check Flow> Fig. 10A is a diagram showing a flow example (part 4) of the requirements definition support method of this embodiment, and Fig. 10B is a diagram showing a flow example (part 5) of the requirements definition support method of this embodiment.

[0084] In this embodiment, the consistency check unit 13 performs a consistency check on sentences or requirements that are determined to be of a low-context requirement type as a result of the requirement type determination (S11) by the requirement type determination unit 11. First, the consistency check on non-functional requirements will be described. In this case, the consistency check unit 13 performs the following steps S31 to S34 on each low-context sentence or requirement that is the subject of the check.

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

[0086] In other words, "the requirement targets are the same or similar and the requirement contents are partially the same" means that the category sets are the same or similar (a certain percentage or more of the number of categories are the same), and the non-functional requirements (keywords) and the sets of quantitative or qualitative indicators for each category are not completely identical but are only partially different (for example, the non-functional requirement (keyword) used for the category "availability" is the same, "uptime", but the values ​​of the "quantitative indicator" for uptime are different). In other words, in step S31, similar requirements are selected that have roughly the same specifications but differ only in the values ​​of the quantitative or qualitative indicators that indicate non-functional requirements.

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

[0088] The consistency check unit 13 also determines whether all of the quantitative or qualitative indicators extracted in S32 match between the requirement to be checked and the requirement selected in step S31 (S33). If the result of this determination is that all of the quantitative or qualitative indicators match (S33: Yes), the consistency check unit 13 returns to S30 to process the next requirement.

[0089] On the other hand, if the result of the above determination is that there is a mismatch in the quantitative indicators or the qualitative indicators (S33: No), the consistency check unit 13 determines that a contradiction has occurred between the requirement being checked and the requirement selected in step S31 (S34), and returns the process to S30 to process the next requirement. Note that the presence or absence of such a contradiction is the determination result of step S14 in each flow of Figures 7 and 8, and is the subject of a notification of the occurrence of a contradiction.

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

[0091] Therefore, the consistency check unit 13 selects other sentences or requirements from the requirements DB 20 whose requirement targets are identical or similar to the low-context sentence or requirement being checked and whose requirement contents partially match (S41). The requirement targets are, for example, a set of "categories" in the functional requirement standards 22A. The requirement contents are, for example, a set of "keywords" for each category in the functional requirement standards 22A.

[0092] In other words, when the requirement targets are the same or similar and the requirement contents are partially the same, it refers to a situation where the category sets are the same or similar (a certain percentage or more of the number of categories are the same) and the sets of keywords for each category are not completely identical but are only partially different (for example, the keywords used for the categories "user" and "business" are the same, but the keywords related to the category "data" are different).

[0093] Next, the consistency check unit 13 extracts 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 being checked and the requirement selected in step S41 (S43: Yes), the consistency check unit 13 returns the process to S40 to process the next requirement.

[0095] On the other hand, if the result of the comparison shows that the sets of keywords extracted in S42 do 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 process the next requirement. Note that the presence or absence of such a contradiction is the result of the determination in step S14 in each flow of Figures 7 and 8, and is the subject of a notification of the occurrence of a contradiction.

[0096] 12 shows an example of a screen G10 displayed when a contradiction has been detected as a result of the above-mentioned consistency check and the result is sent to the user terminal 30. The screen G10 shown here includes at least a requirement display field G101 that displays to the user the content of a combination of requirements for which a contradiction has been detected as a result of the consistency check, a radio button G102 that asks the user whether the requirements of the combination are described in relation to the same specification, and an input field G103 that accepts from the user the entry of correct requirement content that aggregates the requirements of the above-mentioned combination.

[0097] The user views screen G10 and recognizes that the requirements are nearly identical but have different non-functional requirement values, resulting in a contradiction. If these requirements can be aggregated and expressed as a single requirement, the user selects "Yes" in radio button G102. In this case, the user responds to the requirements definition support device 10 by entering the correct requirement content in input field G103 and clicking the "Submit" button at the bottom of the screen. This operation corresponds to "requesting additional input" in step S15 in each flow of Figures 7 and 8. In other words, the correct requirement is provided to the requirements type determination unit 11 as the next target for requirement type determination.

[0098] <Requirements Definition Support Method: Loop Determination Flow> FIG. 11 is a diagram showing a flow example (part 6) of the requirements definition support method of this 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 prevent the requirements generation process in the large-scale language model 41 from being repeated multiple times unnecessarily for the same sentence or requirement. To achieve this, the flow identifies and eliminates meaningless requirements generation loops. Note that the following description will be an example of capturing an event in which requirements generation starting from the same requirement, etc. is repeated twice, but it is also possible to capture an event that is generated three or more times repeatedly.

[0099] If the above-mentioned events are left undetected, the requirements generation by the large-scale language model 41 will not lead to the generation of low-context requirements, resulting in a situation where time and computer resources will be wasted.

[0100] Therefore, the loop determination unit 12 executes steps S51 to S55 in the flow of Fig. 11 for each high-context requirement. Prior to starting this flow, the loop determination unit 12 searches the requirements DB 20 or the main storage device 102 for sentences or requirements related to a specific development project that are identical to the sentences or requirements that served as the starting point for generation.

[0101] By performing this search, a tree structure, i.e., a hierarchical relationship, between each of the sentences and requirements stored in the requirements DB 20, etc., becomes clear, where the hierarchy deepens and branches with each requirement generation. In this embodiment, the depth of such a hierarchical relationship is managed as follows: the sentence or requirement (existence) that is the starting point for generation is defined as the 0th order, the first requirement generation (using the large-scale language model 41) for that sentence, etc. is defined as the 1st order, and the requirement generation that is further executed using the requirements resulting from this 1st order requirement generation as input is defined as the 2nd order. Furthermore, the requirements that are the subject of processing by the loop determination unit 12 are defined as the nth order.

[0102] The loop determination unit 12 treats requirement A, which has been determined to be a high context by the requirement type determination unit 11, as having been obtained in the nth-order requirement generation in the hierarchical relationship of the tree structure described above. The loop determination unit 12 determines whether there is requirement A obtained in the nth-order requirement generation and a requirement B that is several orders higher than the nth-order requirement (for example, a requirement obtained in the n-2th-order requirement generation) (S51).

[0103] If the result of the above determination is that there is no higher-level requirement B (S51: No), the loop determination unit 12 ends this flow and returns to step S50 to start processing for the next high-context requirement. On the other hand, if the result of the above determination is that there is a higher-level requirement B (S51: Yes), the loop determination unit 12 calculates the similarity between the above-mentioned requirement A and requirement B (S52). The calculation of the similarity is performed, for example, by calculating the matching rate of keywords included in the description of the requirement.

[0104] Next, the loop determination unit 12 determines whether the similarity calculated in step S52 exceeds a reference threshold value (S53). If the result of this determination is that 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 next high-context requirement.

[0105] On the other hand, if the result of the above judgment is that the similarity exceeds the threshold value (S53: Yes), the loop judgment unit 12 judges that a loop has occurred when generating requirements using the large-scale language model 41, that is, that high-context requirements of the same level are being continuously regenerated (S54), and ends this flow as the target of step S18 in the main flow.

[0106] The loop determination unit 12 delivers a screen G15 shown in FIG. 13 to the user terminal 30 regarding the n-th order requirement where such a loop has occurred and the n-2-th order sentence or requirement above it. The user viewing this screen G15 inputs the correct requirement content regarding the high-context requirement where the loop has occurred and responds to this to the requirements definition support device 10. The requirements definition support device 10 treats the requirement content received from the user terminal 30 as the subject of determination by the requirements type determination unit 11.

[0107] <Screen example: Loop determination result> As shown in Figure 13, the above-mentioned screen G15 at least has a requirement content field G151 that shows the requirement content between the high-context requirements that make up the loop, and an additional information input field G152 that accepts input of additional information from the user regarding the requirement.

[0108] The user browses the requirement content field G151 on the screen G15 and recognizes requirements of different generations with roughly the same content that have been repeatedly generated by the large-scale language model 41 starting from the same sentence or requirement. Then, for such requirements, the user enters the correct requirements in the additional information input field G152. The user then responds to the requirements definition support device 10 by clicking the "Submit" button at the bottom of the screen. This operation corresponds to "requesting additional input" in step S18 in each flow of Figures 7 and 8. In other words, the requirements with the correct content are provided to the requirement type determination unit 11 as the target for the next requirement type determination.

[0109] <Screen example: Tree structure>

[0110] As a result of the series of processes described so far, requirements DB 20 stores n-th order requirements sequentially generated by large-scale language model 41, starting from a sentence (requirement) written in natural language entered by the user, while maintaining their hierarchical relationships as information. Based on the sentence and requirement information stored in requirements DB 20, requirement output unit 15 can identify a series of derivation relationships from the sentence (written in natural language) that was the starting point for generating requirements to each of the n-th order requirements.

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

[0112] In addition, the requirements output unit 15 performs display control on the objects G201 arranged in a tree structure, including the text or requirement object identified by the consistency checking unit 13 as the subject of a contradiction, or the object for which the user has input additional information regarding such a requirement, by adding an icon G202 or text indicating the occurrence of the contradiction, or by coloring the object G201 or widening the line width, and performing various other highlighting displays.

[0113] A user viewing screen G20 with the above-described display control can visually recognize and easily understand the content and derivation relationships of each requirement that makes up the requirements definition for the target development project, as well as the existence of any contradictions that have arisen among them. This leads to the user being able to take appropriate and prompt action against problem areas, and is expected to improve the quality of the overall requirements definition and increase work efficiency.

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

[0115] The above description can be summarized as follows: The following summary may include supplementary explanations and explanations of variations of the above description.

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

[0117] This allows for efficient and accurate identification of the context characteristics of the text (written in natural language by a human) to be input to the large-scale language model and the requirements generated based on that text, improving the efficiency of the entire subsequent flow. Ultimately, it makes it possible to more efficiently generate a highly accurate, low-context requirements tree structure from a natural language description.

[0118] Furthermore, in the requirements definition support system of this embodiment, if the control of further requirement generation extends to the nth order due to the requirement including a high-context element, the system may further include a loop determination unit that calculates the similarity between the requirement obtained in the nth order requirement generation and the text or a requirement that is several orders higher than the nth order, and determines whether a loop in requirement generation has occurred based on the similarity, and if the result of the determination indicates that a loop in requirement generation has occurred, accepts user input of correct requirement content regarding the nth order requirement in which the loop has occurred and the text or the higher-order requirement, and treats the requirement of that requirement content as the target for determining the requirement type.

[0119] This effectively prevents the repetition of meaningless repetition of requirements generation using large-scale language models for the same sentences or requirements. Furthermore, by allowing user intervention in the processing of such sentences or requirements, the accuracy of subsequently generated requirements can be ensured. Ultimately, this enables more efficient generation of more accurate, low-context requirements tree structures from natural language descriptions.

[0120] Furthermore, the requirements definition support system of this embodiment further includes a requirements DB that stores the text and the requirements, and a consistency check unit that, if the result of the determination regarding the requirement type is that the text or the requirement is a low-context requirement type, selects from the requirements DB other text or requirements that have the same or similar requirement target and partially identical requirement content as the text or requirement that was the subject of the determination, and outputs a message that a contradiction that needs to be resolved has occurred between the text or requirement and the other text or requirement, and that accepts user input to resolve the contradiction regarding the output that indicates the occurrence of the contradiction, and the requirement with the requirement content corresponding to the user input may be used to determine the requirement type.

[0121] This makes it possible to accurately identify specifications that impair consistency within the entire project, such as when low-context sentences or requirements that describe the same function or configuration contain different numerical values, and to accept confirmation actions by the user. Ultimately, it becomes possible to more efficiently generate a high-precision low-context requirements tree structure from descriptions in natural language.

[0122] Furthermore, the requirements definition support system of this embodiment may further include a requirements output unit that outputs a series of derivation relationships from the sentence to each of the n-th order requirements based on the information on the sentence and the requirements stored in the requirements DB (an example of requirements information) in a display format in which objects corresponding to the sentence and each of the requirements are arranged in a tree-like manner, and display control is performed to indicate the occurrence of a contradiction for the sentence or requirement object in which the contradiction occurs, among the objects arranged in the tree-like manner.

[0123] This system visually clarifies the hierarchical structure of requirements (non-functional and functional requirements) sequentially generated as needed using a large-scale language model, starting from a user's natural language description, and helps users understand the situation. While displaying this information, the system also allows users to intervene in problematic areas, enabling the establishment of a problem-free requirements definition overall. Ultimately, it enables the efficient and accurate generation of a low-context requirements tree structure with high accuracy and no discrepancies from natural language descriptions.

[0124] Furthermore, the requirements definition support system of this embodiment may further include a requirements knowledge DB (an example of requirements knowledge information) that holds requirement histories related to past cases, and an editing processing unit that, when a requirement generated by the large-scale language model includes a high-context element, selects from the requirements knowledge DB requirement histories of past cases whose requirement targets or requirement contents match or are similar to the sentence or the requirement, and edits the sentence or the requirement based on the requirements history, and the requirements detailing unit inputs the sentence or the requirement that has been edited into the large-scale language model to generate requirements.

[0125] This makes it possible to effectively utilize knowledge from similar past cases, effectively improving the accuracy and efficiency of requirements generation, and ultimately enabling more efficient generation of low-context requirements tree structures from natural language descriptions.

[0126] N Network 1 Requirements definition support system 10 Requirements definition support device 11 Requirement type determination unit 12 Loop determination unit 13 Consistency check unit 14 Requirement detailing unit 15 Requirement output unit 16 Editing processing unit 20 Requirement DB 21 Requirement knowledge DB 22 Context level determination criteria DB 30 User terminal 40 Service providing system 41 Large-scale language model 100 Information processing device 101 Auxiliary storage device 102 Main storage device 103 Program 104 Arithmetic device 105 Input device 106 Output device 107 Communication device

Claims

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

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

3. When the control of the further requirement generation due to the requirements including high-context elements reaches a plurality of times up to the nth time, calculate the similarity between the requirements obtained in the nth requirement generation and the text or the requirements at a level higher than the nth time by more than one level, and based on the similarity, further comprising a loop determination unit that determines whether a loop in requirement generation occurs. As a result of the determination, when the loop in requirement generation has occurred, the loop determination unit accepts user input of correct requirement content regarding the nth requirement in which the loop has occurred and the text or the higher-level requirements, and sets the requirements of the requirement content as the determination target of the requirement type. The requirement definition support system according to claim 2.

4. The requirement information storing the text and the requirements, and a consistency check unit that outputs that a contradiction to be resolved has occurred between the text or the requirement and another text or requirement that has the same or similar requirement target and partially matching requirement content, which is selected from the requirement information when the text or the requirement is a low-context requirement type as a result of the determination regarding the requirement type. For the output indicating that the contradiction has occurred, the requirement type determination unit accepts a user input for resolving the contradiction and sets the requirement with the requirement content corresponding to the user input as the determination target of the requirement type. The requirement definition support system according to claim 3.

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

6. Requirement knowledge information that holds the requirement history of past cases, and an editing processing unit that, when the requirement generated by the large language model includes high-context elements, selects from the requirement knowledge information the requirement history of past cases whose requirement target or requirement content is the same or similar to the text or the requirement, and edits the text or the requirement based on the requirement history. The requirement refinement unit inputs the text or the requirement that has undergone the editing into the large language model to generate requirements. The requirement definition support system according to claim 1.

7. A requirement definition support method performed by a computer, which includes obtaining a text related to requirement definition, inputting 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 when the requirement generated by the large language model includes high-context elements, inputting the requirement into the large language model and executing control for further requirement generation.

8. A requirement definition support program that causes a computer to execute the following: obtain a sentence related to requirement definition, input the sentence into a large language model that automatically generates a requirement definition when the sentence includes high-context elements, to generate a requirement consisting of low-context elements, and when the requirement generated by the large language model includes high-context elements, input the requirement into the large language model and execute control to perform further requirement generation.

Images