Requirements specification creation device, requirements specification creation method, and requirements specification creation program

Abstract

To reduce a load for preparing a request specification.SOLUTION: A specification acquisition unit 21 acquires specification data which has a specification model indicating, for each constituent element constituting an existing system, specification of the constituent element, and where change comments indicating change contents of the specification are imparted to at least a part of the specification model. A request model generation unit 23 generates a request model corresponding to an objective specification model with each of one or more specifications to which the change comments are imparted as objects, and sets the change comments imparted to the objective specification models as child models belonging to the request models. A request specification preparation unit 24 prepares the request specification by displaying the request model and the child model, and by setting a parent model at a higher position to the plurality of request models.SELECTED DRAWING: Figure 1

Description

Technical Field

[0002] , , , ,

[0004] , , , , , ,

[0006] , , , , , , , , , , , , ,

[0005] ,

[0003] ,

[0001] The present disclosure relates to a technique for assisting in creating a requirements specification when creating a specification for a new system using the specification of an existing system.

Background Art

[0002] In system development, a model-based systems engineering approach may be adopted to create the most upstream system design document using a visually represented model. The model is described using a modeling language such as UML and SysML. UML is an abbreviation for Unified Modeling Language. SysML is an abbreviation for Systems Modeling Language. Developers create specific hardware and software design documents using the system design document.

[0003] In recent years, it is rare to develop a system completely from scratch, and it is often the case that a new system is developed by reusing a similar existing system. When developing a new system by reusing an existing system, a system design document for the new system is created based on the design document of the existing system.

[0004] Patent Document 1 describes a technique for assisting in the task of creating a design document for a new system using the design document of an existing system. In Patent Document 1, the design document of the existing system is compared with the design document created by modifying the design document of the existing system to determine the relevance between the modified parts.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] When creating a system specification, the first step is to create a requirements specification document that summarizes the requirements for the system. These requirements are what the system is intended to achieve. Then, to satisfy the requirements outlined in the requirements specification document, functional specifications and other documents are created that specify the functions of the system. When developing a new system using an existing system, a requirements specification document is created that summarizes the change requests for the existing system. These change requests are features that were not implemented in the existing system but are desired in the new system. Then, a functional specification document is created, outlining the changes to the functions to meet the requirements outlined in the requirements specification document.

[0007] System developers are engineers. Therefore, system developers have no problem technically describing specific changes in functional specifications and other documents. On the other hand, system developers often have difficulty summarizing and expressing only the change requests for existing systems. For this reason, in system development environments, functional specifications and other documents are sometimes created first, and requirements specifications are created afterward. When requirements specifications are created retrospectively, they are drafted by referring to functional specifications and other documents. However, even then, creating the requirements specifications is time-consuming.

[0008] Patent Document 1 describes a technology that assists in the process of creating design documents for a new system using design documents for an existing system. However, Patent Document 1 does not describe a method for reducing the burden of creating requirements specifications.

[0009] This disclosure aims to reduce the burden of creating requirements specifications when creating specifications for a new system using the specifications of an existing system. [Means for solving the problem]

[0010] The requirements specification creation device related to this disclosure is: A specification acquisition unit acquires specification data in which each component constituting an existing system has a specification model representing the specifications of that component, and in which change comments indicating the changes in the specifications are attached to at least some of the specification models. A request model generation unit generates a request model corresponding to each of the specification models to which the change comments have been attached, among the specification models in the specification data acquired by the specification acquisition unit, and sets the change comments attached to the target specification model as child models belonging to the request model. A requirements specification creation unit that displays the requirements model and child models generated by the requirements model generation unit and sets a parent model above multiple requirements models, thereby creating a requirements specification document. It is equipped with. [Effects of the Invention]

[0011] In this disclosure, a requirements model and child models are generated by adding modification comments to the specification model of specification data created using model-based systems engineering. Then, by setting a parent model above the requirements model, a requirements specification can be easily created using model-based systems engineering. [Brief explanation of the drawing]

[0012] [Figure 1] Configuration diagram of the requirements specification creation device 10 according to Embodiment 1. [Figure 2] A flowchart showing the operation flow of the requirements specification creation device 10 according to Embodiment 1. [Figure 3] An explanatory diagram of the specification data relating to Embodiment 1. [Figure 4] An explanatory diagram of the specification data for the new system according to Embodiment 1. [Figure 5] An explanatory diagram of the request model generation process according to Embodiment 1. [Figure 6] An explanatory diagram of the mapping table 31 according to Embodiment 1. [Figure 7] Explanatory drawing of the requirement model 43 and the child model 44 according to Embodiment 1. [Figure 8] Configuration diagram of the requirement specification creation device 10 according to Modification 1. [Figure 9] Explanatory drawing of the change comment 41 according to Embodiment 2. [Figure 10] Explanatory drawing of the change type according to Embodiment 2. [Figure 11] Explanatory drawing of the conflict identifier 46 according to Embodiment 2. [Figure 12] Configuration diagram of the requirement specification creation device 10 according to Embodiment 3. [Figure 13] Explanatory drawing of the parent proposal section 25 according to Embodiment 3.

Mode for Carrying Out the Invention

[0013] Embodiment 1. ***Explanation of Configuration*** Referring to FIG. 1, the configuration of the requirement specification creation device 10 according to Embodiment 1 will be described. The requirement specification creation device 10 is a computer. The requirement specification creation device 10 includes hardware of a processor 11, a memory 12, a storage 13, and a communication interface 14. The processor 11 is connected to other hardware via signal lines and controls these other hardware.

[0014] The processor 11 is an IC that performs processing. IC is an abbreviation for Integrated Circuit. As a specific example, the processor 11 is a CPU, a DSP, or a GPU. CPU is an abbreviation for Central Processing Unit. DSP is an abbreviation for Digital Signal Processor. GPU is an abbreviation for Graphics Processing Unit.

[0015] Memory 12 is a storage device that temporarily stores data. Specific examples of memory 12 include SRAM and DRAM. SRAM stands for Static Random Access Memory. DRAM stands for Dynamic Random Access Memory.

[0016] Storage 13 is a storage device for storing data. A concrete example of storage 13 is an HDD. HDD stands for Hard Disk Drive. Alternatively, storage 13 may be a portable recording medium such as an SD® memory card, CompactFlash®, NAND flash, flexible disk, optical disk, compact disk, Blu-ray® disc, or DVD. SD stands for Secure Digital. DVD stands for Digital Versatile Disk.

[0017] Communication interface 14 is an interface for communicating with external devices. Specific examples of communication interface 14 include Ethernet®, USB, and HDMI® ports. USB stands for Universal Serial Bus. HDMI stands for High-Definition Multimedia Interface.

[0018] The requirements specification creation device 10 comprises a specification acquisition unit 21, a candidate extraction unit 22, a requirements model generation unit 23, and a requirements specification creation unit 24 as functional components. The functions of each functional component of the requirements specification creation device 10 are implemented by software. Storage 13 stores programs that implement the functions of each functional component of the requirements specification creation device 10. These programs are loaded into memory 12 by the processor 11 and executed by the processor 11. This realizes the functions of each functional component of the requirements specification creation device 10.

[0019] The mapping table 31 is stored in storage 13.

[0020] In Figure 1, only one processor 11 was shown. However, there may be multiple processors 11, and multiple processors 11 may work together to execute programs that implement each function.

[0021] ***Explanation of operation*** Referring to Figures 2 to 7, the operation of the requirements specification creation device 10 according to Embodiment 1 will be explained. The operation procedure of the requirements specification creation device 10 according to Embodiment 1 corresponds to the requirements specification creation method according to Embodiment 1. Furthermore, the program that realizes the operation of the requirements specification creation device 10 according to Embodiment 1 corresponds to the requirements specification creation program according to Embodiment 1.

[0022] Referring to Figure 2, the operation flow of the requirements specification creation device 10 according to Embodiment 1 will be explained. (Step S1: Specifications acquisition process) The specification acquisition unit 21 acquires specification data for the new system, to which change comments 41 indicating the changes have been added to the specification data of the existing system.

[0023] Here, we assume that specification data for the existing system is created using a modeling language. The specification data includes various types of specifications, such as functional specifications that describe the specifications of functions and structural specifications that describe the specifications of the structure. The specification data has a specification model that represents the specifications of each component that makes up the existing system. The specification data represents the relationships between components, including parent-child relationships, through connections between specification models. For example, in a functional specification document, as shown in Figure 3, each function that constitutes an existing system has a functional model, which is a specification model, and the functional models of related functions are connected by relationship lines. In Figure 3, the functional models are hierarchically organized, and the hierarchy and relationship lines represent parent-child relationships.

[0024] As shown in Figure 4, the specification data for the new system has one or more change comments 41 attached to at least some of the specification models in the specification data of the existing system. Figure 4 shows an example of change comments 41 being attached to the functional specification shown in Figure 3. Change comments 41 are attached by the developers. Change comments 41 specifically describe the changes to the specifications.

[0025] (Step S2: Candidate extraction process) The candidate extraction unit 22 extracts specification models from the specification data obtained in step S1 that may have forgotten to have change comments 41 added, as change candidates 42. Specifically, the candidate extraction unit 22 recursively extracts a specification model as a candidate for change 42 that does not have a change comment 41 and is sandwiched between at least one of the specification models that has a change comment 41 and a specification model extracted as a candidate for change 42. "Sandwiched" means the following cases (1) and (2): (1) Two or more specification models at the same hierarchical level are connected. (2) A specification model at the parent hierarchical level is connected to a specification model at the child hierarchical level.

[0026] In Figure 4, functional model B is connected to two functional models at the same hierarchical level, functional model A and functional model C, which have been given change comments 41. Therefore, functional model B is extracted as change candidate 42. Next, functional model E is connected to functional model B, which was extracted as change candidate 42, as a parent functional model, and functional model F, which has been given change comments 41, is connected as a child functional model. Therefore, functional model E is extracted as change candidate 42.

[0027] (Step S3: Extraction determination process) The candidate extraction unit 22 determines whether or not a candidate change 42 was extracted in step S2. If a candidate for change 42 is extracted by the candidate extraction unit 22, the process proceeds to step S4. On the other hand, if no candidate for change 42 is extracted by the candidate extraction unit 22, the process proceeds to step S6.

[0028] (Step S4: Warning Processing) The candidate extraction unit 22 displays the candidate change 42 extracted in step S2 and warns that it may have forgotten to add the change comment 41. For example, the candidate extraction unit 22 displays the candidate change 42 surrounded by a red frame.

[0029] (Step S5: Change detection process) The candidate extraction unit 22 receives input from the system developer regarding whether or not to modify the specification data in response to the warning. If the candidate extraction unit 22 receives input to change the specification data, it returns to step S1 to obtain the changed specification data. On the other hand, if the candidate extraction unit 22 receives input to not change the specification data, it proceeds to step S6.

[0030] (Step S6: Requirements model generation process) The requirements model generation unit 23 generates a requirements model 43 by referring to the mapping table 31 and draws it in the requirements specification document 50. Specifically, the requirements model generation unit 23 sets one or more specification models with change comments 41 attached from the specification data obtained in step S1 as the target specification model. Then, as shown in Figure 5, the requirements model generation unit 23 generates a requirements model 43 corresponding to the target specification model. Furthermore, the requirements model generation unit 23 sets the change comments 41 attached to the target specification model as child models 44 belonging to the generated requirements model 43. If the target specification model has multiple change comments 41 attached, the requirements model generation unit 23 sets a child model 44 corresponding to each change comment 41. Setting a child model 44 belonging to the requirements model 43 means generating a child model 44 corresponding to the change comment 41 and connecting the requirements model 43 and the child model 44 with a relationship line indicating that it belongs to the requirements model 43.

[0031] As shown in Figure 6, the mapping table 31 has a manual area 32 and an automated extraction area 33. The automated extraction area 33 has a model area 34 for each model type. The model type is a type of specification model, such as a functional model or a structural model. The requirements model generation unit 23 draws the generated requirements model 43 and child models 44 in the corresponding model area 34 in the automatic extraction area 33. For example, if the functional model is the target specification model, the requirements model generation unit 23 draws the requirements model 43 and child models 44 in the model area 34 corresponding to the functional model in the automatic extraction area 33.

[0032] (Step S7: Requirements specification creation process) The requirements specification creation unit 24 displays the requirements model 43 and child models 44 generated in step S6 and sets a parent model 45 above the multiple requirements models 43. As a result, the requirements specification creation unit 24 creates the requirements specification document 50. Specifically, as shown in Figure 7, the requirements specification creation unit 24 displays the requirements model 43 and child models 44 for each drawn specification model. The requirements specification creation unit 24 then instructs the system developer to set a parent model 45 in the manual area 32 and connect the parent model 45 with the multiple requirements models 43 associated with the parent model 45 using relationship lines. At this time, the parent model 45 is set with change requests for the existing system that are common to the change comments attached to the source specification model from which the multiple connected requirement models 43 were generated. In other words, the requirements specification creation unit 24 accepts input of the parent model 45 and the connection lines, as well as the change requests for the existing system that are common to the change comments attached to the source specification model from which the models were generated.

[0033] ***Effects of Embodiment 1*** As described above, the requirements specification creation device 10 according to Embodiment 1 generates a requirements model 43 and a child model 44 from the specification data to which the change comments 41 have been added, and sets the parent model 45. As a result, system developers can create a requirements specification 50 simply by adding the change comments 41 to the specification model in the specification data and setting the parent model 45. Here, writing change comments 41 to the specification model is a task that system developers will find relatively easy. Furthermore, setting the parent model 45 is also relatively easy, as it only involves describing the higher-level concepts of the listed requirements models 43. Therefore, it is possible to reduce the burden of creating the requirements specification.

[0034] ***Other configurations*** <Example 1> In Embodiment 1, each functional component was implemented in software. However, in Modification 1, each functional component may be implemented in hardware. The differences between this Modification 1 and Embodiment 1 will be explained below.

[0035] Referring to Figure 8, the configuration of the requirements specification creation device 10 according to modified example 1 will be explained. When each functional component is implemented in hardware, the requirements specification creation device 10 includes an electronic circuit 15 instead of the processor 11, memory 12, and storage 13. The electronic circuit 15 is a dedicated circuit that implements the functions of each functional component, as well as the functions of the memory 12 and storage 13.

[0036] Electronic circuits 15 can include single circuits, complex circuits, programmed processors, parallel programmed processors, logic ICs, GAs, ASICs, and FPGAs. GA stands for Gate Array. ASIC stands for Application Specific Integrated Circuit. FPGA stands for Field-Programmable Gate Array. Each functional component may be implemented in a single electronic circuit 15, or each functional component may be implemented by distributing them across multiple electronic circuits 15.

[0037] <Modification 2> As a second variation, some of the functional components may be implemented in hardware, while others may be implemented in software.

[0038] The processor 11, memory 12, storage 13, and electronic circuit 15 are collectively referred to as the processing circuit. In other words, the function of each functional component is realized by the processing circuit.

[0039] In addition, the term "part" in the above explanation may be replaced with "circuit," "process," "procedure," "processing," or "processing circuit."

[0040] Embodiment 2. Embodiment 2 differs from Embodiment 1 in that the change comment 41 warns of potential conflicts. Embodiment 2 explains this difference, while omitting explanations of the similarities.

[0041] ***Explanation of operation*** As shown in Figure 9, change comment 41 is assigned a change type corresponding to the specification change, and an explanation is added. The change type is a classification of the effects obtained by the specification change, and there are (1) to (11) as shown in Figure 10. The explanation is the specific effect obtained by the specification change. As shown in Figure 10, there are changes that have a positive influence on each other and changes that have a negative influence on each other. In Figure 10, the row change type and the column change type with a "+" have a positive influence on each other. The row change type and the column change type with a "-" have a negative influence on each other. When a field is blank, there is almost no influence between the row change type and the column change type. In other words, matching the change comment 41 assigned to the row change type (marked with "+") with the change comment 41 assigned to the column change type results in a synergistic effect. On the other hand, matching the change comment 41 assigned to the row change type (marked with "-") with the change comment 41 assigned to the column change type may result in negative effects such as canceling each other out.

[0042] In step S6 of Figure 2, the request model generation unit 23 sets a conflict identifier 46 between the child models 44 corresponding to two change comments 41 attached to the target specification model if the assigned change type is a change type that has a negative impact. For example, as shown in Figure 11, a conflict identifier 46 is set between the child model 44 corresponding to the change comment 41 to which the change type of (2) performance efficiency is assigned, and the child model 44 corresponding to the change comment 41 to which the change type of (5) interoperability is assigned.

[0043] ***Effects of Embodiment 2*** As described above, the requirements specification creation device 10 according to Embodiment 2 sets a conflict identifier 46 between child models 44 corresponding to change comments 41 to which a change type that has a negative impact has been assigned. This makes it possible to detect defects in change comments 41 when creating the requirements specification document 50.

[0044] Embodiment 3. Embodiment 3 differs from Embodiments 1 and 2 in that it proposes setting a common parent model 45 for multiple request models 43. Embodiment 3 will explain this difference, while the same points will not be explained.

[0045] ***Explanation of the structure*** Referring to Figure 12, the configuration of the requirements specification creation device 10 according to Embodiment 3 will be described. The requirements specification creation device 10 differs from the requirements specification creation device 10 shown in Figure 1 in that it includes a parent proposal unit 25 as a functional component. The function of the parent proposal unit 25 is implemented by software or hardware, similar to other functional components. Furthermore, the requirements specification creation device 10 differs from the requirements specification creation device 10 shown in Figure 1 in that one or more setting statements 35 are stored in the storage 13.

[0046] ***Explanation of operation*** In step S7 of Figure 2, the parent proposal unit 25 determines whether any of the one or more setting statements 35 stored in the storage 13 are commonly included in the change comments 41 attached to two or more specification models. If they are commonly included, the parent proposal unit 25 proposes a common parent model 45 setting to the request model 43 generated from the two or more specification models. For example, as shown in Figure 13, the requirements specification creation unit 24 displays the requirements model 43 and child models 44 for each drawn specification model. In this case, the change comment 41 corresponding to child model 44X and the change comment 41 corresponding to child model 44Z both contain a common setting statement 35. In this case, the parent proposal unit 25 proposes a setting for a parent model 45 that is common to both the requirements model 43A to which child model 44X belongs and the requirements model 43B to which child model 44Z belongs. In Figure 13, the parent proposal unit 25 proposes the setting for the parent model 45 by showing the parent model 45 with a dashed line.

[0047] ***Effects of Embodiment 3*** As described above, the requirements specification creation device 10 according to Embodiment 3 proposes the setting of a common parent model 45 based on the wording set in the change comment 41. This reduces the burden associated with setting the parent model 45.

[0048] The various aspects of this disclosure are summarized below as an appendix. (Note 1) A specification acquisition unit acquires specification data in which each component constituting an existing system has a specification model representing the specifications of that component, and in which change comments indicating the changes in the specifications are attached to at least some of the specification models. A request model generation unit generates a request model corresponding to each of the specification models to which the change comments have been attached, among the specification models in the specification data acquired by the specification acquisition unit, and sets the change comments attached to the target specification model as child models belonging to the request model. A requirements specification creation unit that displays the requirements model and child models generated by the requirements model generation unit and sets a parent model above multiple requirements models, thereby creating a requirements specification document. A requirements specification creation device equipped with the following features. (Note 2) The parent model is configured with change requests for the existing system that are common to the change comments attached to the specification model from which the multiple request models originated. The requirements specification creation device described in Appendix 1. (Note 3) The aforementioned specification data represents the relationships between components through connections between the specification models. The aforementioned requirements specification creation device further Candidate extraction unit extracts specification models from the specification data that do not have the aforementioned change comments attached, and that are sandwiched between specification models that do have the aforementioned change comments attached, as candidate change models. A requirements specification creation device as described in Appendix 1 or 2, comprising the following features. (Note 4) The candidate extraction unit extracts, as new candidate changes, specification models from the specification data that do not have the change comment attached to them, and that are sandwiched between at least one of the specification models with the change comment attached and one of the candidate changes. The requirements specification creation device described in Appendix 3. (Note 5) The aforementioned change comment has a change type assigned to it. The request model generation unit sets a conflict identifier between the child models corresponding to the two change comments if the assigned change type between the two change comments attached to the target specification model is a change type that has a negative impact. A requirements specification creation device as described in any one of the items 1 to 4 in the appendix. (Note 6) The aforementioned requirements specification creation device further If any of the one or more setting statements are included in the change comments attached to two or more specification models, the parent proposal unit proposes a common parent model setting to the request model generated from the two or more specification models. A requirements specification creation device described in any one of the appendices 1 to 5, comprising the above. (Note 7) A computer acquires specification data in which each component constituting an existing system has a specification model representing the specifications of that component, and in which change comments indicating changes to the specifications are attached to at least some of the specification models. The computer generates a request model corresponding to each of the specification models to which the change comment has been attached, among the specification models contained in the specification data, and sets the change comment attached to the target specification model as a child model belonging to the request model. A method for creating a requirements specification, wherein the computer displays the requirements model and the child models and sets a parent model above multiple requirements models to create a requirements specification document. (Note 8) A specification acquisition process that acquires specification data having a specification model representing the specifications of each component that constitutes an existing system, and in which change comments indicating the changes in the specifications are attached to at least some of the specification models, A request model generation process that, for each of the specification models in the specification data obtained by the specification acquisition process that has the change comment attached to it, generates a request model corresponding to the target specification model, and sets the change comment attached to the target specification model as a child model belonging to the request model, A requirements specification creation process that displays the requirements model and child models generated by the requirements model generation process and sets a parent model above multiple requirements models to create a requirements specification document. A requirements specification creation program that makes a computer function as a requirements specification creation device.

[0049] The embodiments and variations of this disclosure have been described above. Some of these embodiments and variations may be implemented in combination. Alternatively, some or all of them may be implemented in part. However, this disclosure is not limited to the embodiments and variations described above, and various modifications are possible as needed. [Explanation of Symbols]

[0050] 10 Requirements specification creation device, 11 Processor, 12 Memory, 13 Storage, 14 Communication interface, 15 Electronic circuit, 21 Specification acquisition unit, 22 Candidate extraction unit, 23 Requirements model generation unit, 24 Requirements specification creation unit, 25 Parent proposal unit, 31 Mapping table, 32 Manual area, 33 Automatic extraction area, 34 Model area, 35 Setting text, 41 Change comment, 42 Change candidate, 43 Requirements model, 44 Child model, 45 Parent model, 46 Conflict identifier, 50 Requirements specification document.

Claims

1. A specification acquisition unit acquires specification data in which each component constituting an existing system has a specification model representing the specifications of that component, and in which change comments indicating the changes in the specifications are attached to at least some of the specification models. A request model generation unit generates a request model corresponding to each of the specification models to which the change comments have been attached, among the specification models in the specification data acquired by the specification acquisition unit, and sets the change comments attached to the target specification model as child models belonging to the request model. A requirements specification creation unit that displays the requirements model and child models generated by the requirements model generation unit and sets a parent model above multiple requirements models, thereby creating a requirements specification document. A requirements specification creation device equipped with the following features.

2. The parent model is configured with change requests for the existing system that are common to the change comments attached to the specification model from which the multiple request models originated. A requirements specification creation apparatus according to claim 1.

3. The aforementioned specification data represents the relationships between components through connections between the specification models. The aforementioned requirements specification creation device further Candidate extraction unit extracts specification models from the specification data that do not have the aforementioned change comments attached, and that are sandwiched between specification models that do have the aforementioned change comments attached, as candidate change models. A requirements specification creation device according to claim 1, comprising:

4. The candidate extraction unit extracts, as new candidate changes, specification models from the specification data that do not have the change comment attached to them, and that are sandwiched between at least one of the specification models with the change comment attached and one of the candidate changes. The requirements specification creation apparatus according to claim 3.

5. The aforementioned change comment has a change type assigned to it. The request model generation unit sets a conflict identifier between the child models corresponding to the two change comments if the combination of the change type assigned to one of the two change comments attached to the target specification model and the change type assigned to the other change comment is a combination of change types that negatively affect each other. A requirements specification creation apparatus according to claim 1.

6. The aforementioned requirements specification creation device further If any of the setting statements are included in the change comments attached to two or more specification models, the parent proposal unit proposes a common parent model setting to the request model generated from the two or more specification models. A requirements specification creation device according to claim 1, comprising:

7. A computer acquires specification data in which each component constituting an existing system has a specification model representing the specifications of that component, and in which change comments indicating changes to the specifications are attached to at least some of the specification models. The computer generates a request model corresponding to each of the specification models to which the change comment has been attached, among the specification models contained in the specification data, and sets the change comment attached to the target specification model as a child model belonging to the request model. A method for creating a requirements specification, wherein the computer displays the requirements model and the child models and sets a parent model above multiple requirements models to create a requirements specification document.

8. A specification acquisition process that acquires specification data having a specification model representing the specifications of each component that constitutes an existing system, and in which change comments indicating the changes in the specifications are attached to at least some of the specification models, A request model generation process that, for each of the specification models in the specification data obtained by the specification acquisition process that has the change comment attached to it, generates a request model corresponding to the target specification model, and sets the change comment attached to the target specification model as a child model belonging to the request model, A requirements specification creation process that displays the requirements model and child models generated by the requirements model generation process and sets a parent model above multiple requirements models to create a requirements specification document. A requirements specification creation program that makes a computer function as a requirements specification creation device.

Images