JP5747698B2 - Requirements management support device - Google Patents

Description

  The present invention relates to a support apparatus for efficiently managing requirements and specifications of software and describing a document efficiently.

  As a method for efficiently producing high-quality software, there is a method in which requirements (requirement items) necessary and sufficient for the software system are first defined and each requirement is refined step by step. In this method, for example, there are three stages of refinement, and a design document is developed such as a requirement specification, a design, and a detailed design.

  In this case, the requirement specifications define requirements that are necessary and sufficient for the software system. In the design document, based on the contents described in the requirement specification, it is divided into a set of functions to realize the required items, and the mechanism is designed. In the detailed design document, the design is divided and detailed to a level corresponding to the implementation form of the program based on the contents divided and described in the design document, and the design at the implementation level is described.

  For example, Patent Document 1 discloses a technique for managing specifications by refining requirements step by step using a diagram-type management unit as shown in FIG. 6 and by associating an attribute called TAB with the attribute. Has been.

  By the way, in order to produce the software correctly, it is necessary to create the lower-level document so that the contents described in the higher-level document do not leak and do not include unnecessary ones. For this reason, a method has been devised in which an upper document and a lower document are associated and managed.

  For example, in Patent Document 2, the design information identification ID is provided in addition to the design information in the software product, and the relationship between the design information identification IDs in the software product is stored via the design information analysis unit. A technique for managing the system is disclosed.

Also, Patent Document 5 discloses a technique for management based on the relationship among defect reports, source codes, correction reports, internal designs, unit test documents, external designs, and required specifications.
The relationship required between these documents is also required between the design document and the test specification. For example, if there are three levels of detail as described above, check the specifications for each item described in the requirement specification, and check the design items for each item described in the design document. Therefore, it is necessary to check the mounting items corresponding to each item of the detailed design document so that it does not contain any unnecessary items.

  For example, Patent Document 3 discloses a technique for appropriately matching by extracting a test item from a function included in a source file and automatically generating a corresponding unit test standard based on the source file (source code). It is disclosed.

  In this way, by managing the correspondence between design documents and between design documents and test specifications, it is possible to prevent item leaks and avoid mixing unnecessary items, so software can be produced correctly. However, for that purpose, it is necessary to efficiently confirm that the related information (link information) managed between the design documents or between the design documents and the test specifications is appropriate.

For example, Patent Document 1 discloses a technique for managing the association between design information and reliably confirming whether upstream process design information is expanded into downstream process design information.
However, in order to perform such management, it is necessary to sequentially input related information between documents, and there are problems such as an increase in the number of work steps and a source of human error. Such a problem is also pointed out in Patent Document 4, and this document discloses a technique for extracting a candidate with a keyword when a link is established and saving the link.

  Conventionally, a system (tool) called “requirement management system (tool)” or “requirement management system (tool)” is known. Such a requirement / requirement management system is used to support setting of links between requirements (requirements) and to ensure traceability. Also, so-called “traceability matrix” is managed. Specific examples of such a system (tool) include, for example, products such as IBM's (formerly Telelogic) 's DOORS (Rational DOORS) (registered trademark) and IBM's RequisitePro (registered trademark). ing.

  The requirement (request) management system that has been commercialized has a function of creating a database of the description contents of each specification as one item and one record, a function of accepting setting of links between requirements (requests) by operation from the GUI, A function for searching and displaying a corresponding part of another specification corresponding to a requirement (request) of a specification is provided.

  And as described in the above-mentioned patent document 4, regarding the above-mentioned “function to accept setting of links between requirements (requests) by operation from GUI”, the related items of each specification must be linked manually. For this reason, there is a problem that the user is burdened and a link mistake is easily caused. In order to solve this problem, in Patent Document 4, link destination candidates are automatically extracted based on keywords included in the requirements (requests) of the link source specification.

  An example of each of the above specifications is the above-described required specification, design, detailed design, etc., but is not limited to this example.

JP-A-6-202859 JP 2007-199755 A JP 2003-177942 A Japanese Patent Laid-Open No. 2008-192059 JP 2002-182908 A

  In this way, software can be accurately and efficiently managed by using technology that prevents items from leaking and avoids mixing of unnecessary items by managing the correspondence between design documents and between design documents and test specifications. Although it can be manufactured, it is necessary to implement this efficiently.

  For example, according to the technique disclosed in Patent Document 4, when a design document or the like has already been created and there is a change, this method efficiently finds a corresponding portion and improves the input efficiency of related information. It was possible, but if the document was created first and the corresponding document has not been created yet, after entering the document, it is also possible to search for each keyword and enter related information Can not escape.

  An object of the present invention is to generate a plurality of documents each having a chapter number and can be related to each other, and to link items between documents more efficiently and to prevent item leakage. It is to provide a requirement management support device and the like.

  The requirement management support apparatus of the present invention is an apparatus that supports the creation of a plurality of documents that each have a chapter number and can be related to each other, and is a document that arbitrarily creates one or more of the documents. One of the created documents and the created document is set as a higher-level document, and a model of a lower-level document as another document related to the higher-level document is generated based on the higher-level document. A template generating unit; and a related information generating unit that generates related information indicating a relationship between each item of the higher-order document and each item of the lower-order document. The creation of the lower-level document based on the template is supported.

  In the requirement management support apparatus having the above configuration, for example, the template generation unit derives a document configuration specified by the chapter configuration of the lower-order document from a document configuration specified by the chapter configuration of the higher-level document. , A template of the lower document is generated.

  In the requirement management support apparatus having the above-described configuration, for example, the template generation unit is configured to generate the subordinate based on a document configuration defined by a chapter number as a base point arbitrarily set and a chapter configuration of the higher-order document. A model of the subordinate document is generated by deriving the chapter number and title name of the side document.

  According to the requirement management support apparatus, if at least one document is created among a plurality of documents each having a chapter number and can be related to each other, the other documents are based on the created documents. Since a template is created and related information, which is information for linking between documents, is automatically generated, the user's labor for document creation and linking can be reduced. In addition, it is possible to prevent mistakes such as item leakage and link leakage.

  According to the requirement management support apparatus and the like of the present invention, it is possible to generate a plurality of documents each having a chapter number, which can be related to each other, and to link each item between documents more efficiently. It will also be possible to prevent item leakage. Even when a document is changed, it can be efficiently maintained.

  When creating a new document, it is possible to efficiently create a document and to build correspondence data between documents. This makes it possible to create a document more efficiently, prevent item leakage, and eliminate unnecessary items. It can be carried out.

It is a functional block diagram of the requirement management assistance apparatus of this example. It is a figure which shows the hardware structural example of the terminal device of this example. It is a figure which shows the structural example of the document stored in a document storage part. It is a conceptual diagram which shows the relationship between a high-order document, a low-order document, and related information. It is a figure which shows the specific example of a high-order document, a low-order document, and related information. It is a specific example of related information (link information). It is a flowchart figure of a lower side document model production | generation process. An example of a specific data structure when the higher-level document is a requirement specification and the lower-level document is a type test specification It is a specific example of a related list. It is a process flowchart figure in the case of outputting using an outline function. It is an example of the screen of a requirement management assistance apparatus. It is an example of a template creation screen. It is a production | generation process flowchart figure of a related list.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 shows a functional configuration diagram of the requirement management support apparatus 1 of this example.
The requirement management support apparatus 1 in the illustrated example includes an upper document analysis unit 2, a lower document generation unit 3, a related information generation unit 4, a document storage unit 5, a document output unit 6, a document input unit 7, and a related information analysis unit. It has various functional parts such as 8. The document storage unit 5 stores, for example, various documents 5a and related information 5b.

The requirement management support apparatus 1 can be constructed on, for example, a general-purpose electronic computer terminal (personal computer) 10 as shown in FIG.
A personal computer 10 shown in FIG. 2 includes a main storage device 11, a display device 12, an auxiliary storage device 13, an input device 14, an arithmetic device 16, and the like, which are connected to an internal bus 15 so that data can be transmitted and received between them. It has become.

  The main storage device 11 is, for example, a memory. The auxiliary storage device 13 is a hard disk or the like, for example, and stores a predetermined application program in advance. The arithmetic device 16 is, for example, a CPU / MPU or the like, and by reading and executing the application program, the various functional units (upper side document analysis unit 2, lower side document generation unit 3, and related information generation shown in FIG. Unit 4, document output unit 6, document input unit 7, related information analysis unit 8, etc.). The document storage unit 5 may be considered to correspond to the auxiliary storage device 15. In other words, for example, the auxiliary storage device 15 may store the various documents 5a and the related information 5b. However, the present invention is not limited to this example.

The display device 12 is, for example, a liquid crystal display, and the input device 14 is, for example, a keyboard, a mouse, or the like, but is not limited to these examples.
The various documents 5a stored in the document storage unit 5 are various design documents such as requirement specifications, design documents, and detailed design documents described in the above prior art. As a typical example, as described above, there is a relationship between a relatively higher-order document and a lower-order document, but the present invention is not limited to this typical example. The design document is an example, and the design document is not limited to this example. Also, it is assumed that the various documents 5a to which the present technique is applied have chapter numbers.

  From the above, it can be said that the various documents 5a are, for example, a plurality of documents that each have a chapter number and can be related to each other. The chapter number means, for example, a chapter / section / item number, but is not limited to this example. Here, for example, those that do not include numbers such as A, B, C,..., And those that include symbols and numbers such as A1, A2, A3,. , “Chapter number” (however, it is necessary to have some regularity in order to automatically generate and assign chapter numbers).

  In addition, the upper document and the lower document in this description typically mean the relatively higher document and the lower document in the various design documents, but the present invention is not limited to this example. For example, it may be considered that anything is possible as long as “the template of the lower document is generated based on the upper document”.

  Of the various documents 5a, the upper document is analyzed by the upper document analysis unit 2, and a template of the lower document is automatically generated by the lower document generation unit 3 based on the analysis result. The template of the lower document is formed by automatically generating a chapter number together with each title based on the upper document. Further, the related information generation unit 4 automatically generates related information between documents (link information between items of arbitrary two documents). The generated lower-order document is stored in the document storage unit 5. The generated related information (such as link information) is also stored in the document storage unit 5.

  In the requirement management support apparatus 1 of this example, the document structure defined by the chapter structure of the lower document is derived from the document structure defined by the chapter structure (chapter / section / section structure, etc.) of the higher document. , Provided as a template for lower-level documents. A document creator completes a document by arbitrarily inputting detailed design information or the like in the template.

  In addition, the related information generation unit 4 generates and registers related information 5b between any two documents (for example, a higher-order document and a lower-order document). A specific example of the related information 5b is shown in FIG. 6 and will be described later.

  Further, for example, in order to maintain the correspondence when the document is changed, the related information 5b can be generated and output in the form of a list. That is, the related information analysis unit 8 automatically generates a list indicating the relationship (for each item) of each document based on the document 5a and the related information 5b stored in the document storage unit 5. The related list is stored in the document storage unit 5. A specific example of the related list is shown in FIG. 9 and will be described later.

  Further, the document output unit 6 converts the various documents 5a, the related list, and the like into a format that can be edited by a word processor, an editor, a spreadsheet, or the like outside the requirement management support apparatus 1 and outputs the converted document. The related list may be externally output as it is.

  Here, the document format in the requirement management support apparatus 1 is based on a requirement (request) management tool such as Doors (manufactured by IBM). Documents managed by the requirement (request) management tool are provided with links between documents (links between related items of documents), for example. The items of each document are managed in cell units.

  Of course, Doors (manufactured by IBM) is an example of a requirement (request) management tool, and is not limited to this example. Generally, multiple documents related to each other are managed by a requirement (request) management tool, and in particular, links between the above documents (links between related items of the document) and chapter numbers (traceability is controlled). Securing) is important.

  The external word processor is, for example, WORD (Word; manufactured by Microsoft Corporation), but is not limited to this example. The external output process may be performed by the document output unit 6, for example, but is not limited to this example. For example, the document output unit 6 may simply output the various documents 5a without conversion.

  The output document may be accompanied by document structure information (for example, hierarchy / level, title or text). The relationship between the constituent elements (items) of each document may be identified in the relationship list.

  Further, various documents and related lists edited by the external word processor, editor, spreadsheet, etc. may be taken into the requirement management support apparatus 1 via the document input unit 7. At that time, related information (link information) between documents is automatically generated based on the information in the related list.

FIG. 3 shows a configuration example of the document 5 a stored in the document storage unit 5.
In the illustrated example, the document 5a is composed of a title part 31 having a chapter number (chapter / section / item number, etc.) and a body part 32 that does not have a chapter number and explains the contents of the parent title. There may be a plurality of body parts 32 for one title part 31. Further, there may be a title part 31 below the title part 31, and there may be a plurality of title parts 31 below the title part 31. That is, the title section 31 corresponds to a “heading” such as “chapter / section / section”, and typically has a section at the lower part of the chapter and a section at the lower part of the section (in other words, There is a section above the term, and a chapter above the section). Of course, there may be multiple sections under any chapter, as well as multiple sections under any section.

  In the illustrated example, for example, “3 development requirement” corresponds to a chapter, “3” corresponds to a chapter number, and “development requirement” corresponds to a chapter heading (title). For example, “3.1 requirement A” and “3.2 requirement B” correspond to clauses, “3.1” and “3.2” are node numbers, and “requirement A” and “requirement B” are Corresponds to the section heading (title).

  However, here, everything is explained as a chapter without using sections and terms. Therefore, here, '3.1' and '3.2' are also assumed to be chapter numbers. Therefore, “requirement A” and “requirement B” will be described as equivalent to chapter headings (titles). However, “3.1 Requirement A” and “3.2 Requirement B” are different in hierarchy from “3 Development Requirements”.

  That is, the title part 31 and the text part 32 are managed in a hierarchical structure (tree structure). In the example shown in FIG. 3, “3 development requirements” is the highest hierarchy (for example, hierarchy 1), There are “3.1 requirement A” and “3.2 requirement B” in the hierarchy (for example, hierarchy 2), and a hierarchical structure in which the text portion 32 is in the lower hierarchy.

  FIG. 4 is a conceptual diagram showing the relationship between the high-order document and the low-order document related by the related information generation unit 4 and related information. Between the upper document 21 and the lower document 22, the related items (the title part 31 and the body part 32 in FIG. 3) are associated by the related information 23 (5b).

FIG. 5 shows a specific example of the upper side document, the lower side document, and related information.
In the example shown in FIG. 5, the higher-order document is a requirement specification, and the lower-order document is a design document (respectively, only a part thereof is shown). In FIG. 5, the related information is indicated by an arrow, but an actual data example is as shown in FIG.

In the case of the example in FIG. 5, the contents described in the requirement specifications are further detailed and described in the design document.
In FIG. 5, the structure of the upper document is shown on the left side. Also, the structure of the lower document is shown on the right side. In addition, the information associated with each item of two documents indicated by arrows in FIG. 5 and FIG. 8 described later is related information 5b.

  Each document is managed in units of cells, for example. In FIG. 5 and the like, it is assumed that each rectangle means one cell. For example, the rectangles enclosing “3. Development requirement”, “3.1 Requirement A”, “Configuration 1 of requirement A”, “4.1.1 Requirement A”, “Design 1 of configuration 2 of requirement B”, etc. , Each means one cell. A unique identification ID may be assigned to each cell for management.

  The apparatus 1 automatically generates a template of a lower document (design document) based on, for example, a higher document (required specification). An example of a design document shown on the right side of FIG. This shows a state in which the user has input arbitrary data based on a simple template. For example, the description of the text part 32 such as “design 1 of the configuration 1 of requirement A” shown in the figure is arbitrarily input by the user.

  On the other hand, the contents (chapter number and title name) of the title part 31 such as “4.1.1 Requirement A” and “4.1.1.1 Configuration 1 of Requirement A” are automatically generated based on the required specifications. (It already existed at the above template stage). However, the title part 31 (especially with respect to the title name) is not limited to the example of using the automatically generated one as it is. For example, even if the user automatically modifies / changes the automatically generated one. Alternatively, the user may arbitrarily input without performing automatic generation.

  Although the data structure of the requirement specification is as described in FIG. 3, it may be considered that the design document is substantially the same. From this, the title portion is denoted by reference numeral 31 as shown in the figure. The part is denoted by reference numeral 32. The same applies to FIG. 8 described later.

The automatic template generation process will be described later with reference to FIG.
In the requirement specification shown in FIG. 5, development requirements designed in more detail in the design document are described in Chapter 3 (development requirements chapter). In other words, the development requirements designed in more detail in the design document are described starting from Chapter 3.

  Chapter 3 describes the two required items of Chapters 3.1 and 3.2. In addition, the description of the three items is described as the text 32 in the request items of Chapter 3.1. In addition, the description of two items is described as the text 32 in the request item of Chapter 3.2.

  The requirement specifications include chapters other than Chapter 3 before and after Chapter 3 (for example, the outline of the document and the standards that are referred to are described in Chapters 1 and 2). In FIG. 5, it is omitted. In the design document, there are other chapters before and after chapter 4.1, but they are omitted in FIG.

  On the other hand, in the design document of FIG. 5, the content (design item) designed in more detail by receiving the requirement item described in the requirement specification is described in the chapter 4.1 (design chapter) as the base point. However, in order to realize the items described in the required items by design without excess or deficiency, the chapter structure is made to correspond.

  That is, the contents of chapter 3.1 of the requirement specification are received in chapter 4.1.1, and the contents of chapter 3.2 of the requirement specification are received in chapter 4.1.2. Furthermore, in Section 4.1.1.1, the requirement item “Configuration 1 of requirement A” described in the first item of the body part 32 of Chapter 3.1 of the requirement specification is received and used as the title of the design item. “Configuration 1 of requirement A” is described. Such a correspondence relationship is indicated by an arrow in FIG. 5, and the related information 5b holds this correspondence relationship.

  For example, as a more detailed description of the design item “Configuration 1 of requirement A”, in the illustrated example, two text sections 32 (design contents) are described. That is, basically, one or more text parts 32 are described for the title (chapter) in the lowest layer in the title part 31 having a hierarchical structure.

Here, the related information 5b is, for example, data as shown in FIG. 6 and holds the correspondence between the items of the two documents indicated by arrows in FIG.
In the example shown in FIG. 6, chapter numbers are associated with each other with respect to the title portion 31. In the example of FIG. 5, for example, chapter 4.1 of the design document corresponds to chapter 3.1 of the requirement specification, so “3.1, 4.1.1” in the example shown in FIG.

  In the example shown in FIG. 6, when the body part 32 of the higher-order document (required specification) and the title part 31 of the lower-order document (design document) are associated with each other, the identification number assigned to the body part 32 And the chapter number of the title part 31 of the lower-order document are associated with each other. As an example, the identification number assigned to the body part 32 is such that a symbol, a number, or the like is given to a chapter number of the lowermost chapter to which the body part 32 belongs according to a predetermined rule.

  In the example shown in the figure, the rule is that “−m” (m = 1, 2, 3,...) Is assigned to the chapter number of the lowermost chapter. Therefore, as shown in the figure, for example, the three body parts 32 belonging to Chapter 3.1 of the higher-order document (required specification) are sequentially identified by the identification numbers 3.1-1, 3.1-2, 3.1. -3 is assigned, and each chapter number (4.1.1.1, 4.1.1.2, 4.1.1.3) of the lower-level document (design document) is associated with each identification number.

  In the requirement management support apparatus 1 of this example, as described above, a template of the lower document is generated based on the upper document. Here, the processing operation will be described by taking the data structure of FIG. 5 as an example. This processing operation (lower document template generation processing) is executed by the upper document analysis unit 2 and the lower document generation unit 3.

FIG. 7 shows a flowchart of the lower-level document template generation process.
This process is a process of deriving the document structure defined by the chapter structure of the lower-order document from the document structure defined by the chapter structure of the higher-order document and using this as a template for the lower-order document. I can say that.
Further, the processing of FIG. 7 is based on the chapter number as a base point arbitrarily set (for both the upper side and the lower side) and the document configuration defined by the chapter configuration of the upper side document. By deriving the chapter number and title name of the lower document, it can be said that the template of the lower document is generated.

  In the process of FIG. 7, first, the user is caused to make an arbitrary designation. For example, as in the example shown in FIG. 12, the user is allowed to arbitrarily specify the generation source document and the generation destination document, and arbitrarily specify the chapter number of the chapter that is the base point for each document (step S101). In the illustrated example, a requirement specification is specified as a generation source document, and a design document is specified as a generation destination document. Furthermore, the chapter that becomes the base point of each of the requirement specification and the design document is specified. In the case of the example in FIG. 12, the base point of the requirement specification is Chapter 3, and the base point of the design document is Chapter 4.1.

As described above, the higher-order document and the lower-order document may simply be regarded as the generation source document and the generation destination document as described above.
Then, when the user operates a “Generate” button shown in FIG. 12, for example, the processing after Step S102 is started. That is, in this example, the following loop processing is performed for all chapters immediately below the base point of the requirement specification (step S102). In this example, all chapters immediately below mean chapters 3.1 and 3.2. The chapters immediately below are set as items to be processed sequentially, and the following processing is performed on the items to be processed.

  That is, first, a design document item corresponding to a processing target item in the requirement specification is generated (step S103). In this example, even if the item of the requirement specification is the title part 31 or the body part 32, it is generated as the title part 31 on the design document side (chapter number and title are generated). (However, it is not limited to this example). With regard to the chapter number, if the chapter number to be processed is 3.1, this is the base point of chapter 3 + “. 1”, so that it is the base point of the design document, chapter 4.1+ “. 1 ”= Chapter 4.1.1 is generated. The title is copied as it is. In the illustrated example, since the title of Chapter 3.1 is “Requirement A”, the title of Chapter 4.1.1 is also “Requirement A”.

  As described above, after the title part 31 is generated on the design document side, a correspondence (link information between the items) between each item of the requirement specification and the item of the design document is generated (step S104). . This is because, when each item (cell) of the design document is generated in step S103, the item (cell) of the requirement specification that is the generation source is known, and this is stored. Then, for example, the chapter numbers may be associated with each other between the cells corresponding to each other. In the above example, chapters 3.1 and 4.1.1 are associated with each other. As a result, the parts “3.1, 4.1.1” shown in FIG. 6 are generated. However, this is a case where the item of the requirement specification is the title part 31. When the item of the requirement specification is the text part 32, an identification number is assigned to each text part 32 and then associated with the chapter number of the design document. As in the example described above, when the identification number 3.1-1 is assigned to the body part 32, for example, as shown in FIG. Will be done.

  Then, it is determined whether or not there is a child element (immediate item) in the processing target item (step S105). In the example of FIG. 5, “3.1 requirement A” has three child elements (for example, “configuration 1 of requirement A”), and “3.2 requirement B” has two child elements.

  If there is a child element in the item to be processed (step S105, YES), this process (the process of FIG. 7) is recursively called (step S106). When recursively called, the processing target item at that time becomes the base item.

  Therefore, for example, when the processing target item is “3.1 requirement A”, the items immediately below are three items, “configuration 1 of requirement A”, “configuration 2 of requirement A”, and “configuration 3 of requirement A”. Thus, the processes of steps S103 and S104 are executed for each.

  First, regarding step S103, “Configuration 1 of requirement A” or the like is not the title part 31 but the text part 32, and thus has no chapter number. Therefore, for example, the identification number “3.1” is added by adding, for example, “−m” (m; 1, 2, 3,...) Using the chapter number of the processing target item (here, 3.1). -M "is generated. Thus, 3.1-1 for "Configuration 1 of Requirement A", 3.1-2 for "Configuration 2 of Requirement A", 3 for "Configuration 3 of Requirement A" .1-3 are assigned as identification numbers.

  Further, in the process of generating the title part 31 on the design document side, chapter 4.1.1 has already been generated in the above example, so 4.1.1. Generate chapter m ((m; 1, 2, 3,... etc.).

  Then, by performing the processing in step S104, for example, a correspondence relationship indicated by an arrow in FIG. 5 is generated. This is because the related information (link information) 23 (5b) includes portions "3.1-1, 4.1.1.1", "3.1-2, 4.1.1.2", "3.1-3, 4.1.1.3" shown in FIG. Will be generated. The generation of the related information 23 (5b) is executed by the related information generation unit 4, and the generated related information 23 (5b) is stored in the document storage unit 5. Further, as described above, the title name of the processing target item of the higher-order document is copied as it is as the title name in the title portion 31 of the lower-order document. Therefore, in the example illustrated in FIG. 5, for example, “4.1.1.1 Requirement A Configuration 1” is generated for “Requirement A Configuration 1”.

Note that since there is no child element in the “configuration 1 of requirement A” or the like, the determination in step S105 is NO.
When the process related to each child element such as “Configuration 1 of requirement A” is completed, the process returns from the recursively called process. Then, if an unprocessed item remains among the items immediately below the base point, the processing of steps S103 to S106 is performed on this as a processing target. If there is no unprocessed item (if the above processing has been performed for all chapters immediately below the base point of the requirement specification), the process exits the loop and ends this processing.

  In this way, the template is generated, but in the above processing example, as described above, regardless of whether the item of the requirement specification is the title part 31 or the text part 32, it is generated as the title part 31 on the design document side. To do. Therefore, immediately after the generation of the template, a design document without the body part 32 is created. The text part 32 is arbitrarily created and added later by the creator of the design document. Accordingly, each body part 32 (item without a chapter number) in the design document shown in FIG. 5 is arbitrarily input by the user after generating the template, and does not exist in the template.

Next, FIG. 8 shows a specific data structure example in the case where the upper document is a requirement specification and the lower document is a type test specification.
In this case, test items corresponding to the contents described in the requirement specifications are described in the model test specifications. Unlike the case of FIG. 5, in the case of FIG. 8, it is important that the items described in the corresponding requirement specifications and the like are described in the type test specification without excess or deficiency. Deepening is not performed, and it corresponds in the same hierarchy.

  In the case of the example of FIG. 8 as well, the process of generating the lower side document from the upper side document is almost the same as that of FIG. 7, but in the case of the example of FIG. If the item is the title part 31, it is generated as the title part 31 on the type test specification side (that is, the same as in FIG. 7), but the processing target item of the required specification is the body part 32 In this case, the body part 32 is generated in the type test specification, which is slightly different in this respect.

Note that whether or not to deepen the hierarchy may be specified in advance by the user before starting the processing of FIG. 7, for example, but is not limited to this example.
In the example of FIG. 8, for example, the title part 31 “2.1 requirement A” in the design document is generated corresponding to “3.1 requirement A” which is an example of the title part 31 in the requirement specification. However, as already described, the title part 31 (especially with respect to the title name) is not limited to the example of using the automatically generated one as it is. For example, the user can arbitrarily select the automatically generated one. It may be corrected / changed, or may be arbitrarily input by the user without automatic generation.

  Further, for example, a text part 32 “Configuration 1 of requirement A” in the design document is generated corresponding to “Configuration 1 of requirement A” which is an example of the text part 32 in the requirement specification. However, FIG. 8 shows a state after the user additionally inputs an arbitrary sentence. That is, when the user additionally inputs “testing about“ configuration 1 of requirement A ”,“ testing about configuration 1 of requirement A ”is performed as shown in the text part 32 in the design document. ing.

  Then, as in the case of the example of FIG. 5 described in FIG. 7, the correspondence between each item of the requirement specification that is the generation source and the type test specification that is the generation destination is related information (link information). 23 (5b).

  Heretofore, the lower-level document template generation processing executed by the higher-level document analysis unit 2 and the lower-level document generation unit 3 and the related information generation unit 4 generation / storage processing associated therewith have been described.

Hereinafter, processing by other functional units will be described.
In the related information analyzing unit 8, based on the document 5 a and related information 5 b stored in the document storing unit 5, the relationship among the various documents (required specification, design, detailed design, type test specification, etc.) Is automatically generated, and the related list is stored in the document storage unit 5.

FIG. 9 shows an example of a related list stored in the document storage unit 5.
The illustrated association list includes a document identification unit 41 and a chapter configuration correspondence unit 42, and indicates correspondences between various documents (correspondences between items) by chapter numbers. In this example, a detailed specification document is a detailed specification document and a detailed specification document is a detailed specification document. In addition, the type test specification corresponds to the required specification, the functional test specification corresponds to the design, and the unit test specification corresponds to the detailed design.

  The generation process of the related list as shown in FIG. 9 is based on, for example, the correspondence between two documents (each of them) based on the related information 5b of FIG. 6 and the like generated in the lower document template generation process. The process of generating the correspondence between items) is repeated. If described with reference to the example of FIG. 6, in this example, a correspondence relationship between the requirement specification and the design document in the relation list shown in FIG. 9 is generated.

  Although this processing is not particularly illustrated, with reference to related information 5b as in the example shown in FIG. 6, for each row, the left side of the comma (,) is the chapter number of the required specification, and the right side is the chapter number of the design document. Judge. Then, the document identification unit 41 of the relation list in FIG. 9 stores the data on the left side of the comma (,) in the chapter configuration corresponding unit 42 in the column “Required Specifications”. Similarly, the document identification unit 41 of the relation list in FIG. 9 stores the data on the right side of the comma (,) in the chapter configuration corresponding unit 42 in the “design document” column.

  However, in this example, a hyphen (-) and later are not recognized as chapter numbers. Therefore, for example, 3.1-1 and 3.1-2 are all handled as 3.1. Thus, in the example shown in FIG. 9, the chapter numbers of the requirement specifications corresponding to chapters 4.1.1.1 to 4.1.1.3 in the design document are all 3.1.

  Similarly, for example, when a model of a lower-level document (for example, a detailed design document) is created using a design document as a higher-level document, the correspondence between each item of the design document and each item of the detailed design document is changed. Since the related information 5b to be shown is generated and stored, the corresponding part of each chapter number of the design document and the detailed design document in the example shown in FIG. 9 is generated with reference to this. In this example, for example, chapters 5.1.1.1 and 5.1.1.2 of the detailed design document are associated with chapter 4.1.1.1 of the design document.

Next, processing of the document output unit 6 will be described.
The document output unit 6 externally outputs the document 5b stored in the document storage unit 5 and the related list.

  When outputting a document, conversion is performed according to the document format (text, word processor, etc.) of the output destination. Since the document is configured as shown in FIG. 3, the title part 31 having the chapter number and the chapter number are displayed. It is output so that it can be distinguished from the body portion 32 that explains the content without having it. Further, the data is output to the outside while maintaining the hierarchical structure as shown in FIG. In other words, it can be said that the document output unit 6 outputs the various documents 5b having the document structure defined by the chapter structure according to any external document format while maintaining the document structure.

  “Output so that it can be distinguished” means, for example, when outputting in text format, if each line is preceded by a number (chapter number) such as “3.1.1”, the title The method of identifying with the part 31 is pointed out.

  As described above, the document format in the requirement management support apparatus 1 is based on, for example, Doors (manufactured by IBM). However, when the document output unit 6 outputs the document, the format is converted so that the document can be edited externally. Output. For example, to be able to edit with a text editor, output in text format.

  Also, for example, when editing is possible with a word processor, when the chapter data structure can be managed with an outline function for managing the data structure as tree structure data, the chapter title section 31 includes a chapter (heading) on the outline function, The text part 32 may be output as a text on the outline function. For example, Microsoft's Microsoft Word has an outline function.

FIG. 10 shows a processing flowchart for an example of output corresponding to the outline function.
In the case of outputting the related list, it is output in a table format to a word processor or a spreadsheet. This may be output as it is in the format of FIG.

The process of FIG. 10 will be described below with reference to the example of FIG.
First, the user arbitrarily designates a chapter number as a base point (step S900). In this example, it is assumed that, for example, chapter 3 is designated. However, this processing is not necessary if the chapter number as the base point is held as the document attribute.

  Further, the “hierarchy” that is a variable indicating the hierarchy at the output destination is initialized (step S901). Here, for example, “hierarchy” = 0. For example, when the output destination is a word and corresponds to the outline function, this “hierarchy” corresponds to a so-called “outline level”.

  Then, the processing of steps S903 to S907 is performed by referring to the document 5a to be processed one item (one cell; a unit surrounded by a rectangular frame in FIG. 3 and the like) (step S902). When the processes in steps S903 to S907 are executed for all items, this process is terminated. In this example, it is assumed that the processing target document 5a is a design specification and has the contents shown in FIG.

  First of all, it is assumed that the item (Chapter 3; 3 development requirements) as the base point is a processing target item, and its hierarchy is “1”. Then, it is determined whether or not the processing target item is the title part 31 (step S903). Since the above example (3 development requirement) is naturally the title part 31 (step S903, YES), the process proceeds to step S904. If the processing target item is the body part 32 such as “Configuration 1 of requirement A” shown in FIG. 3, for example, the determination in step S903 is NO, and the process proceeds to step S907.

  If step S903 is YES, it is first determined whether or not the hierarchy is the same (step S904). This is to determine whether or not the current hierarchy is the same as the “hierarchy” as the variable. Here, the variable “hierarchy” = 0 in the process of step S901, while the current hierarchy as described above. Is '1' (first layer), the determination in step S904 is NO, and the layer is changed (step S905). That is, the “hierarchy” as a variable is the current hierarchy. Therefore, here, the variable “hierarchy” = 1. Then, a title corresponding to the current variable “hierarchy” is output (step S906) (in this case, since the processing target item is the title part 31, the title name is output). That is, the “3 development requirement” is output to the first layer (level 1) in the tree structure (tree structure) on the outline function. In other words, “Outline Level” = “Level 1” is added and “3 Development Requirements” is output as “Heading”.

  Thus, the output process for the first item is completed, and thereafter, the other items are sequentially output to the outside by the substantially similar process (output corresponding to the tree structure (tree structure) on the outline function). .

  In the example of FIG. 3, since the next item of “3 Development requirement” is “3.1 Requirement A” in the second layer, YES in step S903, NO in step S904, and variable in step S905 “Hierarchy” = 2. As a result, “3.1 Requirement A” is output to the second hierarchy (level 2) in the tree structure (tree structure) on the outline function in step S906. In other words, “3.1 requirement A” is output as “heading” by adding “outline level” = “level 2”.

  Subsequently, since the next item is “Configuration 1 of requirement A”, which is the text portion 32, step S903 is NO, and the text portion 32 (configuration 1 of requirement A) is on the outline function in step S907. Output as “text”. The next and subsequent items “Configuration 2 of Requirement A” and “Configuration 3 of Requirement A” are also output as “text” on the outline function in step S907.

  Since the next item is “3.1 Requirement B” in the second hierarchy, step S903 is YES, and since the variable “hierarchy” = 2 at present, step S904 is YES. Become. Thus, the process of step S906 is performed without changing the hierarchy. Therefore, in step S906, “3.1 requirement B” is output to the second hierarchy (level 2) in the tree structure (tree structure) on the outline function.

  As described above, when the above processing is executed for all items, the user can edit the contents of the document 5a with a word processor (for example, Microsoft Word) (in other words, the user can edit without using the support device 1). In particular, the user can complete the document by inputting arbitrary information to the document 5a in which the template is generated as the lower document.

Then, the document completed on the word processor (for example, Microsoft Word) as described above is returned to the original format by the document input unit 7 and stored in the document storage unit 5.
The user is not limited to this example, and the user may use the support device 1 (without external output) to edit the content of the document 5a to complete the document.

  Note that the related list may also be appropriately edited / modified by the user according to the editing contents of the document by the user (for example, addition / deletion of chapters) after the external output as described above.

Hereinafter, processing by the document input unit 7 will be described.
This will be described without showing a flowchart or the like.
The document input unit 7 takes in the document output externally (or edited after output). As a main application, it is assumed that documents, lists, etc. output by the document output unit 6 are edited externally and imported again. However, the present invention is not limited to this example.

This may be regarded as, for example, processing in which “hierarchy” and “outline level” are reversed in the processing of FIG.
That is, when the document to be imported is, for example, a document with a word outline function, a type such as “headline” or “body” is assigned to each data, and in the case of “headline”, the so-called “outline level” "Is hierarchically managed. Thus, in the case of “Heading”, the data may be taken in as the title part 31 while recognizing the hierarchy by the “outline level”, and in the case of “Body”, the data may be taken in as the body part 32.

  However, this is not sufficient, and link information needs to be generated. That is, after the import is completed, it is necessary to refer to the correspondence relationship in the related list, identify the correspondence relationship between the imported document and other documents, and regenerate the link information.

  For example, when the chapter “4.1.1.4” is newly added due to the above-mentioned external editing work in the “design document”, a new link is used instead of the old link information shown in FIG. Information needs to be generated. Although this new link information is not particularly shown, the line between “3.1-3, 4.1.1.3” and “3.2, 4.1.2” in the link information of FIG. "3.1-4, 4.1.1.4" is newly added.

  It is assumed that the externally output related list accompanying the editing is corrected by an editing operator, for example. In other words, in the example of FIG. 9, “3.1” in “Requirement specification”, “4.1.1.1”, “4.1.1.2” in “Design document”, and Although “4.1.1.3” is associated, “4.1.1.4” is also associated.

  If the process of generating link information from the association list is described using the “required specification” and “design document” as an example, it is first determined whether or not the correspondence is one-to-one. In the above example, “3.1.1.1”, “4.1.1.2”, etc. are associated with “3.1”. It is not 1 (one to plural). Therefore, in this case, all the plural sides (“4.1.1.1”, etc.) are output as they are. On the other hand, the singular side (“3.1”) generates, for example, “3.1-m” (m = 1, 2, 3,...) According to a predetermined rule, Associate. Accordingly, “3.1-1, 4.1.1.1”, “3.1-2, 4.1.1.2”, “3.1-3, 4.1.1” in FIG. .3 "is generated and" 3.1-4, 4.1.1.4 "is added.

  Further, “3.1” itself is associated with the chapter number of the next higher level such as “4.1.1.1”, “4.1.1.2”, and so on. Considering the regularity of chapter numbers, naturally, the chapter number of the layer one level higher than “4.1.1.1” is “4.1.1”, so “3.1” Is associated with “4.1.1”. As a result, “3.1, 4.1.1” in FIG. 6 is generated.

  After that, the chapter numbers of the next higher hierarchy are generated according to the regularity of the chapter numbers in both the “required specification” and the “design document”, and the corresponding processing is performed. One above “3.1” is “3”, and one above “4.1.1” is “4.1”, so that “3, 4.1” in FIG. A part will be generated. This is repeated until, for example, the highest hierarchy is associated.

Others can be generated in substantially the same manner, so that each link information can be generated from the related list.
Note that the processing by the document input unit 7 is not limited to the above-described example. For example, if the document to be imported is a document to which hierarchical information such as “outline level” or a type such as “heading” or “body” is not assigned, the document is imported as follows, for example. You may do it.

  That is, for example, a document to be imported is sequentially scanned, and if it is data that can be identified as a title part, it is taken in as a title part 31, and in other cases, it is taken in as a body part 32. For example, if the first part is a number, it may be determined that it is a title part (however, in this case, for example, a rule such as “the first character is not a number” is used as a description rule of the body part 32 for the user) , Preferably in advance). And when taking in arbitrary data as a title part 31, a hierarchy is determined according to the number of the head part (numbers like 3.1, 3.1.1, 3.1.1.1; chapter number), and the determined hierarchy The data is taken in as data. The method of determining the hierarchy is, for example, '. Depending on the number of ', for example, "hierarchy = number of'. '+ 1" may be set. In this case, it is determined that the above-mentioned 3.1 is level 2, 3.1.1 is level 3, 3.1.1.1 is level 4, and in the case of '3', '. Since there is no ', the layer 1 is determined.

  Note that chapter numbers have a predetermined regularity (numbers from 1, such as 1, 2, 3...). It will never be 3.5 mag. As a result, when the data is imported as the title part 31, a check is performed in accordance with the regularity, and a chapter number (3.5 after 3.3, etc.) that violates the regularity appears. In such a case, an error may be output and the process may be stopped.

FIG. 11 is an example of a screen displayed on the display device 12 of the requirement management support apparatus 1 of this example.
As shown in the figure, an instruction button group 51 for executing main functions is arranged on the upper part of the screen 50 (“model generation”, “document output”, “document capture”, “list”). Generation "). In the area 52 below the command button group 51, the screen can be switched by tabs so that the data of each document can be switched and displayed. In the figure, the “required specification” is displayed. Of course, not only the display but also the user can input arbitrary data to edit the document.

  Further, as shown in the figure, not only the names of documents such as specifications but also “list” is shown in the tab, and when this is selected, the related list shown in FIG. 9 and the like is displayed. The number of documents can be changed according to the number of layers.

Examples of user operations on the screen shown in FIG. 11 are as follows, for example.
For example, the user first describes a requirement specification. Since there is no original document, it is entered directly on the screen of FIG. 11 or created as an external file describing the chapter structure, and is imported by pressing the “document import” button.

  Once the requirement specifications are created as described above, a “model generation” button is pressed to automatically generate a model document. For example, a pop-up screen as shown in FIG. The user can specify a generation source document, a generation destination document, and a base point on the screen of FIG. 12 and then press the “Generate” button to automatically generate a template of the generation destination document. become. In this example, since the created document is only the requirement specification, the generation source document is not limited to the requirement specification. In the illustrated example, a design document template is automatically generated based on the requirement specifications.

  Then, after the design document template is automatically generated, the user designates the “design document” tab on the screen 50 in FIG. 11, and the design document template data is displayed in the area 52. become. The user creates and completes a design document based on this template. That is, for example, in the template, a chapter number is assigned to the title portion 31 and the title is also described (copy of the original document). If you don't think so, you will need to make corrections accordingly. As for the body part 32, the generation source document is copied as described above. However, this is not particularly necessary, and basically the description by the user is always performed. In addition, when describing the text part 32, it may be described while adding and deleting chapters as appropriate.

  When editing, a group of commands such as adding / deleting chapters, switching the text input mode (text input / title input), raising the title chapter one level, lowering the level, etc. Although it is necessary to perform these, these may be realized by inputting a command from a keyboard, for example. Alternatively, although not shown in FIG. 11, buttons corresponding to these commands may be arranged on the screen 50. Further, although only three chapters are displayed on the screen 50 shown in FIG. 11, chapters other than chapter 3 can be simultaneously imported and edited at the time of importing.

  If the editing operation is complicated on the screen of FIG. 11 or if it is desired to print out, the document is output externally. When importing after editing externally, a list is created and also output externally. When chapters are added or deleted externally, the list can be edited in the same manner, so that it is possible to import without conflict even when importing again.

Finally, the related list generation processing shown in FIG. 9 and the like will be described with reference to the flowchart of FIG.
Note that an example of the related list generation processing has already been described, and another example will be described here.

  The process shown in FIG. 13 is a process for extracting and storing the relationship between any two documents (for six documents in the example shown in FIG. 9) for all the documents (between steps S500a-500b). Looping process). This is performed with reference to related information as shown in FIG. 6, for example. Therefore, also in this example, two documents having related information (link information) as shown in FIG. 6 are processed.

  For example, as an example, “required specification” and “design document” are associated (as shown in FIG. 6), “required specification” and “type test specification” are associated, and “design document” ”And“ detailed design document ”,“ design document ”and“ functional test specification ”, and“ detailed design document ”and“ unit test specification ”. It is not limited to the example.

  First, as in step S101, the user designates an arbitrary base point (step S501). Then, in order from the input base point, the processing of steps S503 to S505 (loop processing between steps S502a to s502b) is performed for each item (in this example, the chapter number is not limited to this example) but is sequentially processed. become.

  First, it is determined whether or not the processing target item is “text” (step S503). For example, an item having no chapter number is determined to be “text”. Alternatively, when referring to related information as shown in FIG. 6, if the end is “−number”, it is determined to be “text”.

  If the processing target item is not “text” (step S503, NO), the processing target item (its chapter number and the like) is overwritten and stored in a predetermined area of the memory, for example (step S504). In step S502b, it is determined whether all items have been processed. If not, the process returns to step S502a to set the next item as a processing target.

  On the other hand, when the processing target item is “text” (step S503, YES), the item (chapter number, etc.) stored in the predetermined area of the memory is read out, and this is shown, for example, in FIG. Registered in the relevant section of the related list. Further, an item corresponding to the read item is registered in association with the corresponding portion (step S505). Then, the process proceeds to step S502b.

  Here, for example, “requirement specification” and “design document” are taken as an example (“requirement specification” is associated with source and “design document” is associated with), and “requirement specification” is “3”. '(Chapter 3) is designated as the base point. In this example, since the first processing target item is “3”, step S503 is NO and “3” is stored in the predetermined area. Since the next processing target item is “3.1”, step S503 is NO again, and “3.1” is stored in the predetermined area.

  Since the next process target item is '3.1-1', step S503 is now YES, and the process of step S505 is executed. In this example, “3.1” stored in the predetermined area is stored in the relevant part of the related list (in this example, the field “required specification”), and the current processing target item is The item “design document” corresponding to a certain “3.1-1” is found to be “4.1.1.1” from the example of FIG. In this example, it is stored in the “design document” field). As a result, as shown in FIG. 9, “3.1.1.1” of “design document” is registered in association with “3.1” of “required specification”.

  Further, since the next processing target item is' 3.1-2 ', step S503 is again YES, and the processing of step S505 is executed. However, the stored content of the predetermined area has not changed (' 3.1 'is still stored), as shown in FIG. 9, in the related list, “3.1” of “Required Specification” is replaced with “4.1.1.2” of “Design Document”. Are registered in association with each other.

  Similarly, since the next processing target item is '3.1-3', step S503 is again YES, and the processing of step S505 is executed, but the stored content of the predetermined area is not changed ( As shown in FIG. 9, “3.1” of “Requirements” is added to “4.1.1.3” of “Design”. 'Is associated and registered.

Since the next processing target item is “3.2”, step S503 is now NO, and “3.2” is overwritten in the predetermined area.
Since the next process target item is “3.2-1”, step S503 is YES, and the process of step S505 is executed. At this time, since “3.2” is stored in the predetermined area, as shown in FIG. 9, “design document” is added to “3.2” of “required specification”. "4.1.2.1" is registered in association with each other.

  Further, since the next processing target item is “3.2-2”, step S503 is again YES, and the processing of step S505 is executed. However, the stored content of the predetermined area is not changed (“ 3.2 'is still stored), as shown in FIG. 9, in the related list, “3.2” of “Required Specification” is changed to “4.1.2.2” of “Design Document”. Are registered in association with each other.

  Note that, later, the same items may be combined into one in the related list. Accordingly, as shown in FIG. 9, the above three '3.1' are combined into one, and '4.1.1.1' “4.1.1.2” and “4.1.1.3” are associated and registered. Similarly, the above two '3.2' are combined into one, and '3.1.2.1' and '4.1.2. 2 'is associated and registered.

  Note that the processing algorithm may be switched by the user specifying the type according to the relationship between the two documents to be processed before starting the processing. For example, as an example, if there are two types of documents to be processed, the type shown in FIG. 5 (type A) and the type shown in FIG. 8 (type B), When the user designates type A, the above-described processing of FIG. 13 is executed.

On the other hand, even when the user designates type B, the processing of FIG. 13 described above is basically executed, but there are portions where the algorithm is different.
That is, in the case of type B, if there is no item (chapter number in this example) to be registered in the association destination (“design document” in this example) in step S505, for example, the previous item is output. You may make it do. For example, in the case of the “requirement specification” and “model test specification” shown in FIG. 8, the “model test specification” side is also the “3.1-1” (that is, the main text) of the “requirement specification”. In the above processing, “3.1” is registered for “required specification” in the related list in the above processing, but “model test specification” is an item to be registered in association with this ( In this example, there is no chapter number). Therefore, in this case, “2.1” which is the immediately preceding item is registered. As a result, as shown in FIG. 9, “2.1” is registered in the “type test specification” for “3.1” in the “required specification”.

  As described above, the requirement management support apparatus 1 of the present example derives the document structure defined by the chapter structure of the lower-order document from the document structure defined by the chapter structure of the higher-order document, Provided as a template for lower-level documents. At this time, related information may be generated and registered. The document creator completes the document by inputting detailed design information into the template.

Further, in order to maintain the correspondence when there is a change or the like, the related information may be automatically generated in the form of a list and stored / output.
In addition, the above-described documents and related lists can be externally output so that they can be edited outside the requirement management support apparatus 1 using a word processor, editor, spreadsheet, or the like. At that time, document configuration information is attached to the output document, and the relationship between the components of the document can be identified in the relationship list.

  In addition, these documents and related lists edited with an external word processor, editor, spreadsheet, etc. are imported into the requirement management support device, and in order to maintain the data, The related information may be automatically generated.

  As described above, according to the requirement management support apparatus 1 of the present example, the document structure defined by the chapter structure of the lower-order document is derived from the document structure defined by the chapter structure of the higher-order document, Provided as a template for lower-level documents. At this time, related information (information indicating the correspondence between documents; link information) between each item of the higher-order document and each item of the lower-order document is automatically generated and assigned. The document creator completes the document by inputting detailed design information into the template.

In addition, the related information is automatically generated and output in the form of a list so that the correspondence between documents can be maintained even when the document content is changed.
Also, these documents and lists are output externally so that they can be edited by a word processor, editor, spreadsheet, etc. outside the requirement management support apparatus 1. At that time, document structure information (hierarchy, etc.) is attached to the output document. Further, the list is output together so that the relationship between the document components can be identified in the list.

  In addition, when a user arbitrarily edits a document output to the outside of the requirement management support apparatus 1 as described above using a word processor, editor, spreadsheet, or the like, after editing a list according to the edited document These edited documents and lists may be taken into the requirement management support apparatus 1 again. At this time, related information (link information) between documents is automatically generated based on the information in the list.

  According to the requirement management support apparatus 1 of the present example, generation of a plurality of documents that can be associated with each other with chapter numbers and links between items between documents can be performed more efficiently and item leakage can be prevented. it can. When creating the plurality of documents, for example, if one document is created, for other documents, a template is created based on the created document and linking is automatically performed. Therefore, with respect to other documents, particularly when a new document is created, the document can be efficiently created, and a document managed based on related information (link information) with the other document is automatically created.

  Especially for multiple documents that are assigned chapter numbers and are related to each other, chapter numbers and title names of lower-level documents can be automatically assigned based on higher-level documents. In addition, related chapters can be linked to each other, so that even if there is a change, it can be efficiently maintained. In addition, it is possible to prevent mistakes such as item leakage and link leakage.

  When the plurality of documents are various documents related to software design, correct software can be produced efficiently.

DESCRIPTION OF SYMBOLS 1 Requirements management support apparatus 2 Upper document analysis part 3 Lower document generation part 4 Related information generation part 5 Document storage part 5a Document 5b Related information 6 Document output part 7 Document input part 8 Related information analysis part 10 Terminal (personal computer)
11 Main storage device 12 Display device 13 Auxiliary storage device 14 Input device 15 Bus 16 Computing device 21 Upper document 22 Lower document 23 Related information 31 Title portion 32 Body portion 41 Document identification portion 42 Chapter configuration corresponding portion 50 Screen 51 Command button Group 52 area

Claims (5)

A device that supports creation of a plurality of documents, each of which has a chapter number and can be related to each other,
Document creation support means for arbitrarily creating any one or more of the documents;
One of the created documents is set as a high-order document, and based on the high-order document, a template generation means for generating a model of a low-order document as another document related to the high-order document; ,
Related information generating means for generating related information indicating the relationship between each item of the higher-order document and each item of the model of the lower-order document;
The template generation unit is configured to generate a document structure defined by the chapter structure of the lower-order document based on a chapter number as an arbitrarily set base point and a document structure defined by the chapter structure of the higher-order document. By deriving the chapter number and title name of the lower document, a template of the lower document is generated,
The requirement creation support apparatus, wherein the document creation support means supports creation of the lower-order document based on the template.   2. A related list generating unit that generates a related list that indicates a relationship between items of each document based on the related information between the upper document and the lower document. The requirement management support apparatus described.   The requirement management support apparatus according to claim 1, further comprising a document output unit that outputs the document generated by the document creation support unit to the outside while maintaining the document configuration.   An arbitrary document generated in an external arbitrary document format is converted and input to a document having a document structure defined by the chapter structure, and each item of the input document and other generated documents are The requirement management support apparatus according to claim 1, further comprising a document input unit that generates related information indicating a relationship with each item. Requirements management support apparatus according to claim 1, wherein the document is a design document.

Images