"各々が章番号を有する文書であって相互に関連し得る複数の文書の作成を支援する装置であって、任意の1以上の前記文書を任意に作成させる文書作成支援手段と、前記作成された文書の何れか1つを上位側文書とし、該上位側文書に基づいて、該上位側文書に関連する他の文書としての下位側文書のひな形を生成するひな形生成手段と、前記上位側文書の各項目と下位側文書のひな形の各項目との関連を示す関連情報を生成する関連情報生成手段とを有し、前記文書作成支援手段は、前記ひな形に基づく前記下位側文書の作成を支援することを特徴とする要件管理支援装置。前記ひな形生成手段は、前記上位側文書の章構成で規定される文書構成から前記下位側文書の章構成で規定される文書構成を導出することで、該下位側文書のひな形を生成することを特徴とする請求項1記載の要件管理支援装置。前記ひな形生成手段は、任意に設定される基点となる章番号と前記上位側文書の章構成で規定される文書構成に基づいて、前記下位側文書の章番号、タイトル名を導出することで、該下位側文書のひな形を生成することを特徴とする請求項2記載の要件管理支援装置。前記上位側文書-下位側文書間の関連情報に基づいて、前記各文書間の各項目間の関連を示す関連一覧表を生成する関連一覧表生成手段を更に有することを特徴とする請求項1記載の要件管理支援装置。前記文書作成支援手段で生成された文書を、その文書構成を保ちながら外部出力する文書出力手段を更に有することを特徴とする請求項1に記載の要件管理支援装置。外部の任意の文書形式で生成された任意の文書を、前記章構成で規定される文書構成の文書に変換して入力すると共に、該入力文書の各項目と前記生成されている他の文書の各項目との関連を示す関連情報を生成する文書入力手段を更に有することを特徴とする請求項1に記載の要件管理支援装置。前記文書は設計文書であることを特徴とする請求項1~6の何れかに記載の要件管理支援装置。このように、設計書間や、設計書と試験仕様書間を対応付けて管理することにより、項目もれを防ぎ、かつ、不必要な項目の混入を避ける技術により、ソフトウェアを正確に効率良く製作することができるが、これを効率よく実施することが必要となる。例えば特許文献4で開示されている技術によると、既に、設計文書等が作成されていて、変更があったときには、この方法によって対応する箇所を効率よく発見し、関連情報の入力効率を向上させることが可能であったが、最初に文書を作成し、対応する文書がまだ作成されていない場合には、やはり、文書の入力後に、ひとつひとつキーワードにより検索して関連情報を入力していくという作業を免れることができない。本発明の課題は、各々が章番号を有する文書であって相互に関連し得る複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできる要件管理支援装置等を提供することである。本発明の要件管理支援装置は、各々が章番号を有する文書であって相互に関連し得る複数の文書の作成を支援する装置であって、任意の1以上の前記文書を任意に作成させる文書作成支援手段と、前記作成された文書の何れか1つを上位側文書とし、該上位側文書に基づいて、該上位側文書に関連する他の文書としての下位側文書のひな形を生成するひな形生成手段と、前記上位側文書の各項目と下位側文書のひな形の各項目との関連を示す関連情報を生成する関連情報生成手段とを有し、前記文書作成支援手段は、前記ひな形に基づく前記下位側文書の作成を支援する。上記構成の要件管理支援装置において、例えば、前記ひな形生成手段は、前記上位側文書の章構成で規定される文書構成から前記下位側文書の章構成で規定される文書構成を導出することで、該下位側文書のひな形を生成する。また、上記構成の要件管理支援装置において、例えば、前記ひな形生成手段は、任意に設定される基点となる章番号と前記上位側文書の章構成で規定される文書構成に基づいて、前記下位側文書の章番号、タイトル名を導出することで、該下位側文書のひな形を生成する。上記要件管理支援装置によれば、各々が章番号を有する文書であって相互に関連し得る複数の文書のうち、少なくとも1つの文書を作成すれば、他の文書に関しては作成済みの文書に基づいてひな形が作成されると共に、文書間のリンク付け情報である関連情報が自動的に生成されるので、文書作成及びリンク付けに係るユーザの手間が、軽減できる。更に、項目漏れ、リンク付け漏れ等のミスも防止できる。本発明の要件管理支援装置等によれば、各々が章番号を有する文書であって相互に関連し得る複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできるようになる。文書に変更があった場合にも効率的に維持管理することができる。文書の新規作成時に、効率よく文書作成できると共に、文書間の対応付けデータを構築することができるようになり、より効率的に文書作成できると共に、項目もれの防止、不要な項目の排除を行うことができる。以下、図面を参照して本発明の実施の形態について説明する。図1に、本例の要件管理支援装置1の機能構成図を示す。図示の例の要件管理支援装置1は、上位側文書解析部2、下位側文書生成部3、関連情報生成部4、文書格納部5、文書出力部6、文書入力部7、関連情報解析部8等の各種機能部を有する。文書格納部5は、例えば各種文書5aや関連情報5b等を記憶する。上記の要件管理支援装置1は、例えば、図2に示すような汎用的な電子計算機の端末パソコン10上に構築することができる。図2に示すパソコン10は、主記憶装置11、ディスプレイ装置12、補助記憶装置13、入力装置14、演算装置16等を有し、これらが内部バス15に接続されて相互にデータ送受信等できるようになっている。主記憶装置11は例えばメモリ等である。補助記憶装置13は例えばハードディスク等であり、予め所定のアプリケーションプログラムが記憶されている。演算装置16は、例えばCPU/MPU等であり、上記アプリケーションプログラムを読出し実行することにより、上記図1に示す各種機能部上位側文書解析部2、下位側文書生成部3、関連情報生成部4、文書出力部6、文書入力部7、関連情報解析部8等の機能を実現するものである。尚、上記文書格納部5が、補助記憶装置15に相当するものと考えても良い。つまり、例えば補助記憶装置15には上記各種文書5aや関連情報5bが記憶されるものであってよい。但し、この例に限らない。ディスプレイ装置12は例えば液晶ディスプレイ等あり、入力装置14は例えばキーボード、マウス等であるが、これらの例に限らない。文書格納部5に格納される各種文書5aは、例えば上記従来技術で説明した要求仕様書、設計書、詳細設計書のような各種設計文書である。これは、典型例としては、上記のように相対的に上位側の文書、下位側の文書の関係があるものであるが、この典型例に限るものではない。また、設計文書は一例であり、この例に限るものではない。また、本手法の適用対象となる各種文書5aは、章番号を有するものであることを前提とする。上記のことから、各種文書5aは、例えば、各々が章番号を有する文書であって相互に関連し得る複数の文書であると言うことができる。尚、章番号とは、例えば章/節/項番号等を意味するものとするが、この例に限らない。ここでは、例えば、A,B,C,等のように数字が含まれないものや、A1,A2,A3,等のように記号と数字が混在するものであっても、章番号であるものとする但し、章番号を自動的に生成付与する為に、何らかの規則性を有することが必要である。また、尚、本説明における上位側文書、下位側文書とは、上記各種設計文書における上記相対的に上位側の文書、下位側の文書を意味することが典型例となるが、この例に限らず、例えば上位側文書に基づいて下位側文書のひな形が生成されるものであれば何でもよいと考えても良い。上記各種文書5aのうち上記上位側文書が上位側文書解析部2で解析され、この解析結果に基づいて下位側文書生成部3により下位側文書のひな形を自動生成する。この下位側文書のひな形は、上位側文書に基づいて各タイトルと共に章番号が自動的に生成されて成るものである。更に、関連情報生成部4により、文書間の関連情報任意の2つの文書の各項目間のリンク情報等を自動生成する。生成された下位側文書は文書格納部5に格納される。生成された関連情報リンク情報等も文書格納部5に格納される。本例の要件管理支援装置1では、上位側の文書の章構成章/節/項構成等で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、下位側文書のひな形として提供する。文書作成者は、このひな形に例えば詳細な設計情報等を任意に入力することにより、文書として完成させる。また、上記関連情報生成部4によって、任意の2つの文書間のたとえば上位側文書と下位側文書との関連情報5bが、生成されて登録される。関連情報5bの具体例は図6に示し後に説明する。また、例えば文書に変更等があったときに対応関係を維持するために、この関連情報5bを一覧表の形で生成して出力することもできる。すなわち、関連情報解析部8は、文書格納部5に格納された文書5aや関連情報5b等に基づいて、各文書の各項目毎の関連を示す一覧表を自動的に生成し、この関連一覧表を文書格納部5に格納する。関連一覧表の具体例を図9に示し、後に説明する。また、文書出力部6は、上記の各種文書5aや関連一覧表等を、要件管理支援装置1の外部でワードプロセッサやエディタ、スプレッドシートなどで編集できる形式に変換して、外部出力する。尚、関連一覧表は、そのまま外部出力しても構わない。ここで、要件管理支援装置1内の文書形式は、例えばDoorsIBM社製等のような要件要求管理ツールによるものである。要件要求管理ツールで管理する文書は、例えば、各文書間のリンク文書の各関連項目間のリンクが設けられているものである。また、各文書の項目はセル単位で管理されているものである。勿論、DoorsIBM社製は要件要求管理ツールの一例であり、この例に限らない。一般に、要件要求管理ツールによって、相互に関連する複数の文書が管理されるものであり、特に上記各文書間のリンク文書の各関連項目間のリンクと章番号の管理トレーサビリティを確保することが重要となる。また、外部のワードプロセッサは例えばWORDワード;マイクロソフト社製であるが、この例に限らない。上記外部出力処理は、例えば文書出力部6が行ってよいが、この例に限らない。文書出力部6は、例えば単に各種文書5aを変換なしで外部出力するものであってもよい。尚、出力した文書には、文書構成の情報例えば階層/レベル、タイトルか本文か等を付帯させるようにしてもよい。各文書の構成要素項目同士の関連は、関連一覧表で識別できるようにすればよい。また、上記外部のワードプロセッサやエディタ、スプレッドシートなどで編集後の各種文書や関連一覧表を、文書入力部7を介して要件管理支援装置1内に取り込むようにしてもよい。その際、関連一覧表の情報を元に、文書の間の関連情報リンク情報を自動的に生成する。図3に、文書格納部5に格納される文書5aの構成例を示す。図示の例では、文書5aは、章番号章/節/項番号等を持つタイトル部31と、章番号を持たず、その親になるタイトルの内容を説明する本文部32から成る。本文部32は、タイトル部31ひとつに対して、複数個あっても良い。また、タイトル部31の下位にタイトル部31があってよく、更にタイトル部31の下位に複数のタイトル部31があっても良い。すなわち、タイトル部31は、例えば章/節/項等の見出しに相当し、典型例としては、章の下位に節があり、節の下位に項がある逆に言えば、項の上位に節があり、節の上位に章がある。当然、任意の章の下に複数の節があってよく、同様に、任意の節の下に複数の項があってよい。図示の例では、例えば3開発要件が章に相当し、‘3’が章番号、開発要件が章の見出しタイトルに相当する。また、例えば、3.1要件Aや3.2要件Bが節に相当し、‘3.1’や‘3.2’が節番号、要件Aや要件Bが節の見出しタイトルに相当する。但し、ここでは、節や項等を用いることなく、全てを章として説明する。よって、ここでは、‘3.1’や‘3.2’も章番号であるものとして説明する。従って要件Aや要件Bも章の見出しタイトルに相当するものとして説明する。但し、3.1要件Aや3.2要件Bは、3開発要件とは階層が異なる。すなわち、タイトル部31や本文部32は、階層構造ツリー構造で管理されており、図3に示す例では、3開発要件が最上位階層例えば階層1であり、その下の階層例えば階層2に3.1要件Aや3.2要件Bがあり、更にその下の階層に本文部32がある階層構造となっている。図4は、関連情報生成部4により関連付けを行った上位側文書と下位側文書と関連情報の関係を示す概念図である。上位側文書21と下位側文書22の間は、それぞれの関連する項目図3のタイトル部31や本文部32が、関連情報23により対応付けられている。図5に、上位側文書と下位側文書と関連情報の具体例を示す。図5に示す例では、上位側文書が要求仕様書であり、下位側文書が設計書であるそれぞれ、その一部のみを示す。また、図5では関連情報を矢印で示すが、実際のデータ例は例えば図6に示すようになる。図5の例の場合、要求仕様書に記述された内容が、より詳細化されて、設計書に記述されている。図5では、上位側文書の構造が左側に示されている。また、下位側文書の構造が右側に示されている。また、図5や後述する図8等では矢印で示す、2つの文書の各項目間の対応付けを行っている情報が、関連情報5bである。尚、各文書は、例えばセル単位で管理されている。図5等において各矩形が1つのセルを意味しているものとする。例えば図示の3.開発要件、3.1要件A、要件Aの構成1、411要件A、要件Bの構成2の設計1等を囲う各矩形が、それぞれ、1つのセルを意味している。各セルにそれぞれユニークな識別IDを割当てて管理するようにしてもよい。尚、本装置1では、例えば上位側文書要求仕様書に基づいて下位側文書設計書の雛形を自動生成するが、図5において図上右側に示す設計書の例は、この様な雛形に基づいてユーザが任意のデータを入力した状態を示している。例えば、図示の要件Aの構成1の設計1等の本文部32の記述は、ユーザが任意に入力したものである。一方、4.1.1要件Aや4111要件Aの構成1等のタイトル部31の内容章番号やタイトル名は、要求仕様書に基づいて自動的に生成されたものである上記雛形の段階で既に存在していた。但し、タイトル部31に関しては特にタイトル名に関しては、上記自動生成されたものをそのまま用いる例に限るものではなく、例えば自動的に生成されたものをユーザが任意に修正/変更してもよいし、自動生成を行わずにユーザが任意に入力するようにしてもよい。尚、要求仕様書のデータ構造は図3で説明した通りであるが、設計書も略同様であると考えてよく、これより図示のようにタイトル部には符号31を付してあり、本文部には符号32を付してある。これは、後述する図8等に関しても同様である。上記雛形の自動生成処理については、後に図7等を参照して説明する。図5の要求仕様書では、3章開発要件の章に、設計書にてより詳細に設計される開発要件が記述されている。すなわち、3章を基点として、設計書にてより詳細に設計される開発要件が記述されている。3章には、3.1章、3.2章の2つの要求項目が記述されている。また、3.1章の要求項目には、本文32として、3項目の説明が記述されている。また、3.2章の要求項目には、本文32として、2項目の説明が記述されている。要求仕様書には、3章の前後にも、3章以外の章が含まれるたとえば、文書の概要や、参照している規格などを1章、2章に記述したりする。が、図5では、割愛している。なお、設計書においても、4.1章の前後にも他の章が存在するが、図5では割愛している。一方、図5の設計書では、基点となる4.1章設計の章に、要求仕様書で記述された要求項目を受けて、より詳細に設計した内容設計項目が記述されているが、要求項目に記述された項目を過不足なく設計で実現するために、章構成を対応させている。すなわち、4.1.1章で要求仕様書の3.1章の内容を、4.1.2章で要求仕様書の3.2章の内容を受けている。さらに、4.1.1.1章では、要求仕様書の3.1章の本文部32の第1項目で記述された要件項目要件Aの構成1を受けて、設計項目のタイトルとして要件Aの構成1が記述されている。このような対応関係を図5では矢印で示しており、関連情報5bは、この対応関係を保持している。そして、例えば上記設計項目要件Aの構成1のより詳細な説明として、図示の例では2項目の本文部32設計内容が記述されている。つまり、基本的には、階層構造となっているタイトル部31において最下層のタイトル章について、1項目以上の本文部32が記述されている。ここで、上記関連情報5bは、具体的には例えば図6に示すようなデータとして、図5では矢印で示す上記2つの文書の各項目間の対応関係を保持している。図6に示す例では、タイトル部31に関しては章番号同士を対応付けている。図5の例では例えば要求仕様書の3.1章に対しては設計書の4.1.1章が対応するので、図6に示す例では31,411となっている。また、図6に示す例では、上位側文書要求仕様書の本文部32と下位側文書設計書のタイトル部31とが対応付けられる場合には、本文部32に付与する識別番号と、下位側文書のタイトル部31の章番号とを、対応付けている。本文部32に付与する識別番号は、例えば一例としては、本文部32が属する上記最下層の章の章番号に、予め決められた所定のルールに従って記号、番号等を付与するものである。図示の例では、上記最下層の章の章番号に-mm=1,2,3を付与するルールとしている。よって、図示のように、例えば上位側文書要求仕様書の3.1章に属する3つの本文部32については、順に、識別番号3.1-1、3.1-2、3.1-3が割り当てられており、これら各識別番号に対して下位側文書設計書の各章番号4111、4112、4113が対応付けられている。本例の要件管理支援装置1では、既に述べたように上位側文書に基づいて下位側文書の雛形を生成する。ここでは、図5のデータ構造を例に、その処理動作を説明する。この処理動作下位側文書雛形生成処理は、上位側文書解析部2と下位側文書生成部3によって実行される。図7に、上記下位側文書雛形生成処理のフローチャート図を示す。この処理は、上位側の文書の章構成で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、これを下位側文書のひな形とする処理であると言える。更に言うならば、図7の処理は、上位側と下位側の両方に関して任意に設定される基点となる章番号と、上位側文書の章構成で規定される文書構成とに基づいて、下位側文書の章番号、タイトル名を導出することで、下位側文書のひな形を生成するものであるということも出来る。図7の処理では、まず最初にユーザに任意の指定を行わせる。例えば図12に示す例のように、ユーザに、生成元文書、生成先文書を任意に指定させると共に、各文書について基点となる章の章番号等を任意に指定させるステップS101。図示の例では、生成元文書として要求仕様書が指定され、生成先文書として設計書が指定されている。更に、要求仕様書と設計書それぞれの基点となる章を指定させる。図12の例の場合、要求仕様書の基点は3章、設計書の基点は4.1章である。尚、既に述べたが、上記のように上位側文書、下位側文書を、単に、生成元文書、生成先文書と見做しても構わない。そして、ユーザが例えば図12に示す生成ボタンを操作することで、ステップS102以降の処理を開始する。すなわち、本例では要求仕様書の基点の直下の全ての章について、以下のループ処理を行うステップS102。本例では、直下の全ての章とは、3.1章、3.2章を意味する。直下の各章を順次処理対象項目とし、処理対象とした項目について以下の処理を行う。すなわち、まず、要求仕様書における処理対象の項目に対応する設計書の項目を生成するステップS103。これは、本例では、要求仕様書の項目が、タイトル部31であっても、本文部32であっても、設計書側にはタイトル部31として生成する章番号とタイトルを生成する但し、この例に限らない。章番号に関しては、処理対象の章番号が3.1章であったならば、これは基点である3章.1であるので、設計書における基点である4.1章.1=411章を生成する。また、タイトルは、そのままコピーする。図示の例では、3.1章のタイトルは要件Aであるので、4.1.1章のタイトルも要件Aとなっている。上記のように、設計書側にタイトル部31を生成した後、要求仕様書の各項目と、設計書の項目との間の対応関係各項目間のリンク情報を生成するステップS104。これは、上記ステップS103で設計書の各項目セルを生成した際に、その生成元となった要求仕様書の項目セルは分かっているので、これを記憶しておく。そして、これら相互に対応するセル同士で、例えば各々の章番号同士を対応付ければよい。上記の例では、3.1章と4.1.1章とが対応付けられる。これより、図6に示す31,411の部分が生成されることになる。但し、これは、要求仕様書の項目がタイトル部31であった場合である。要求仕様書の項目が本文部32であった場合には、各本文部32に識別番号を付与したうえで設計書の章番号と対応付ける。既に述べた例のように、本文部32に例えば識別番号3.1-1等が割り当てられた場合には、図6に示すように例えば311,4111などの対応付けが行われることになる。そして、処理対象の項目に子要素直下の項目があるか否かを判定するステップS105。図5の例では、31要件Aに関しては3つの子要素例えば要件Aの構成1等があり、32要件Bに関しては2つの子要素がある。処理対象の項目に子要素がある場合にはステップS105,YES、本処理図7の処理を再帰的に呼び出すステップS106。再帰的に呼び出されたときには、そのときの処理対象項目が、基点の項目となる。従って、例えば処理対象項目が31要件Aであった場合には、上記直下の項目は要件Aの構成1、要件Aの構成2、要件Aの構成3の3つとなり、それぞれについて上記ステップS103、S104の処理が実行されることになる。まずステップS103に関しては、要件Aの構成1等は、タイトル部31ではなく本文部32であるので、章番号が無い。この為、例えば処理対象項目の章番号ここでは3.1を用いて例えば-mm;1,2,3、等を付加することで識別番号3.1-mを生成する。これより、上記要件Aの構成1に対しては3.1-1、要件Aの構成2に対しては3.1-2、要件Aの構成3に対しては3.1-3が、それぞれ識別番号として割り当てられることになる。また、上記設計書側にタイトル部31を生成する処理では、上記の例では4.1.1章が生成済みであるので、その直下の章として4.1.1.m章m;1,2,3、等を生成する。そして、上記ステップS104の処理を行うことで、例えば図5において矢印で示す対応関係が生成される。これは、関連情報リンク情報235bとしては図6に示す311,4111、312,4112313,4113の部分が生成されることになる。尚、関連情報235bの生成は、上記関連情報生成部4が実行するものであり、生成した関連情報235bは上記文書格納部5に格納される。また尚、下位側文書のタイトル部31におけるタイトル名は、上記の通り、上位側文書の処理対象項目のタイトル名を、そのままコピーする。よって、図5に示す例では、例えば要件Aの構成1に対しては、4111要件Aの構成1が生成されることになる。尚、上記要件Aの構成1等には子要素はないので、ステップS105の判定はNOとなる。上記要件Aの構成1等の各子要素に関する処理が完了したら、再帰的に呼び出した処理から復帰する。そして、上記基点の直下の項目のなかで未処理の項目が残っているならば、これを処理対象として上記ステップS103~S106の処理を行う。未処理の項目が無いならば要求仕様書の基点の直下の全ての章について上記処理が行われたならば、ループを抜けて、本処理を終了する。このように、ひな形を生成するが、上記処理例では上記の通り要求仕様書の項目がタイトル部31であるか本文部32であるかに係わらず、設計書側にはタイトル部31として生成する。従って、ひな形生成直後には、設計書には、本文部32が無いものが作成される。本文部32は、設計書の作成者が後に任意に作成追加する。従って、図5に示す設計書における各本文部32章番号が無い項目は、ひな形生成後にユーザが任意に追加入力したものであり、ひな形には存在しなかったものである。次に、図8に、上位側文書が要求仕様書であり、下位側文書が型式試験仕様書である場合の具体的なデータ構造例を示す。この場合、要求仕様書に記述された内容に対応する試験項目が、型式試験仕様書に記述されている。図5の場合と異なり、図8の場合は、対応する要求仕様書などに記述された項目が過不足なく型式試験仕様書に記述されていることが重要であるため、図5のような階層の深化はおこらず、同じ階層での対応となっている。図8の例の場合も、上位側文書から下位側文書を生成する処理は、図7とほぼ同様であるが、図8の例の場合には階層が深化しないので、要求仕様書の処理対象項目がタイトル部31であった場合には型式試験仕様書側にはタイトル部31として生成するがつまり、図7と同じである、要求仕様書の処理対象項目が本文部32であった場合には、型式試験仕様書には本文部32を生成するものであり、この点で多少異なる。尚、階層を深化させるか否かは、例えば予めユーザが図7の処理開始前に指定するものであってよいが、この例に限らない。図8の例では、例えば要求仕様書におけるタイトル部31の一例である3.1要件Aに対応して、設計書におけるタイトル部312.1要件Aが生成される。但し、既に述べたように、タイトル部31に関しては特にタイトル名に関しては、上記自動生成されたものをそのまま用いる例に限るものではなく、例えば自動的に生成されたものをユーザが任意に修正/変更してもよいし、自動生成を行わずにユーザが任意に入力するようにしてもよい。また、例えば要求仕様書における本文部32の一例である要件Aの構成1に対応して、設計書における本文部32要件Aの構成1が生成される。但し、図8には、更にユーザが任意の文章を追加入力した後の状態を示している。すなわち、上記要件Aの構成1にユーザがについて試験する。を追加入力したことで、設計書における本文部32として図示のように要件Aの構成1について試験する。となっている。そして、図7で説明した図5の例の場合と同様に、生成元となった要求仕様書と生成先となった型式試験仕様書の各項目との対応関係を、関連情報リンク情報235bとして記憶しておく。以上、上位側文書解析部2と下位側文書生成部3によって実行される、下位側文書雛形生成処理と、これに伴う関連情報生成部4による関連情報5bの生成格納処理について説明した。以下、他の機能部による処理について説明する。関連情報解析部8では、文書格納部5に格納された文書5aや関連情報5b等に基づいて、上記各種文書要求仕様書、設計書、詳細設計書、型式試験仕様書等間の関連を示す一覧表を自動的に生成し、この関連一覧表を文書格納部5に格納する。図9に、文書格納部5に格納される関連一覧表の一例を示す。図示の関連一覧表は、文書識別部41と章構成対応部42から成り、各種文書間の対応関係その各項目間の対応関係を章番号で示している。この例では、要求仕様書を詳細化したものが設計書であり、設計書を詳細化したものが詳細設計書である。また、要求仕様書に型式試験仕様書が対応しており、設計書に機能試験仕様書が対応しており、詳細設計書に単体試験仕様書が対応している。図9に示すような関連一覧表の生成処理は、例えば上記下位側文書雛形生成処理の際に生成された上記図6等の関連情報5bに基づいて、2つの文書間の対応関係その各項目間の対応関係を生成する処理を、繰り返し行うものである。図6の例を用いて説明するならば、この例の場合には図9に示す関連一覧表のうち要求仕様書と設計書との対応関係が生成されることになる。この処理は、特に図示しないが、図6に示す例のような関連情報5bを参照して、各行毎に、カンマ,の左側が要求仕様書の章番号、右側が設計書の章番号と判断する。そして、カンマ,の左側のデータを図9の関連一覧表の文書識別部41が要求仕様書の列における章構成対応部42に格納する。同様に、カンマ,の右側のデータを図9の関連一覧表の文書識別部41が設計書の列における章構成対応部42に格納する。但し、本例では、ハイフン-以降は章番号として認識しないものとする。従って、例えば、3.1-1や3.1-2等は全て3.1として扱うものとする。これより、図9に示す例では、設計書における4111章~4113章に対応する要求仕様書の章番号は、全て3.1章となっている。他も同様にして、例えば設計書を上位側文書として下位側文書例えば詳細設計書の雛形が作成された場合には、設計書の各項目と詳細設計書の各項目との対応関係を示す関連情報5bが生成格納されるので、これを参照して図9に示す例における設計書と詳細設計書の各章番号の対応関係部分が生成されることになる。この例では、例えば、設計書の4111章に対して、詳細設計書の5111章と5112章が対応付けられている。次に、文書出力部6の処理について説明する。文書出力部6では、文書格納部5に格納された文書5bや上記関連一覧表等を外部出力する。文書を出力するときには、出力先の文書形式テキストやワードプロセッサ等に応じた変換を行うが、図3のように文書が構成されているため、章番号を持つタイトル部31と、章番号を持たず内容を説明する本文部32とが、区別できるように出力する。更に、図3に示すような階層構造を保ちながら、外部出力する。換言すれば、文書出力部6は、上記章構成で規定される文書構成の各種文書5bを、その文書構成を保ちながら外部の任意の文書形式に応じて外部出力するものであると言える。区別できるように出力するとは、例えば、テキスト形式で出力する場合には、各行毎に、その先頭に311のように数字章番号が記載されている場合にタイトル部31と識別するというような方法を指す。上記のように要件管理支援装置1内の文書形式は例えばDoorsIBM社製などによるものであるが、文書出力部6で外部出力する際には外部で編集等が行えるように形式変換して出力する。例えば、テキストエディタで編集できるようにするには、テキスト形式で出力する。また、例えば、ワードプロセッサで編集できるようにする場合には、章のデータ構造を木構造データとして管理するアウトライン機能で管理できる場合には、章のタイトル部31はアウトライン機能上の章見出し、本文部32はアウトライン機能上の本文として出力しても良い。例えば、Microsoft社製のMicrosoftWordはアウトライン機能を備えている。アウトライン機能に対応させて出力する例の場合の処理フローチャート図を、図10に示す。尚、関連一覧表を出力する場合には、ワードプロセッサ、もしくは、スプレッドシートに表形式で出力する。これは、図9の形式のまま、そのまま出力すれば良い。以下、図3の例を参照しながら図10の処理について説明する。まず、ユーザが、基点となる章番号を任意に指定するステップS900。本例では、例えば3章が指定されたものとする。但し、文書属性として基点となる章の番号を保持している場合には、この処理は不要である。更に、出力先における階層を示す変数である階層を初期化するステップS901。ここでは、例えば階層=0とする。例えば、出力先がワードであって且つアウトライン機能に対応させる場合には、この階層は所謂アウトラインレベルに相当することになる。そして、処理対象となる文書5aを1項目1セル;図3等で矩形枠で囲っている単位ずつ参照して、ステップS903~S907の処理を行うステップS902。全ての項目についてステップS903~S907の処理を実行したら、本処理を終了する。尚、本例では処理対象文書5aは設計仕様書であり、図3の内容であるものとする。まず最初は、上記基点となる項目3章;3開発要件が処理対象項目となり、その階層は‘1’であるものとする。そして、処理対象項目がタイトル部31であるか否かを判定するステップS903。上記例3開発要件は当然タイトル部31であるのでステップS903,YES、ステップS904へ進む。尚、処理対象項目が例えば図3に示す要件Aの構成1等のような本文部32であった場合には、ステップS903の判定はNOとなり、ステップS907へ進む。ステップS903がYESの場合には、まず、同じ階層か否かを判定するステップS904。これは、現在の階層が上記変数としての階層と同じか否かを判定するものであり、ここではステップS901の処理により変数階層=0である一方で、上記の通り現在の階層は‘1’1階層目であるので、ステップS904の判定はNOとなり、階層の変更を行うステップS905。すなわち、変数としての階層を、現在の階層とする。よって、ここでは変数階層=1とする。そして、現在の変数階層に応じたタイトルの出力を行うステップS906この場合は処理対象項目はタイトル部31であるのでタイトル名が出力される。つまり、上記3開発要件が上記アウトライン機能上の上記木構造ツリー構造における1階層目レベル1に出力される。換言すれば、アウトラインレベル=レベル1を付加して見出しとして3開発要件を出力する。以上で最初の項目についての出力処理が完了し、以降、他の項目についても順次略同様の処理によって外部への出力上記アウトライン機能上の上記木構造ツリー構造に対応する出力を行う。図3の例では、上記3開発要件の次の項目は、2階層目にある3.1要件Aであるので、上記ステップS903がYES、ステップS904がNOとなり、ステップS905において変数階層=2となる。これより、ステップS906において3.1要件Aが上記アウトライン機能上の上記木構造ツリー構造における2階層目レベル2に出力される。換言すれば、アウトラインレベル=レベル2を付加して見出しとして3.1要件Aを出力する。続いて、次の項目が要件Aの構成1であり、これは本文部32であるので、ステップS903はNOとなり、ステップS907によって本文部32要件Aの構成1がアウトライン機能上の本文として出力される。次とその次の項目である要件Aの構成2、要件Aの構成3に関しても、略同様に、ステップS907によってアウトライン機能上の本文として出力される。そして、さらに次の項目が2階層目にある3.1要件Bであるので、上記ステップS903はYESとなり、更に現状では変数階層=2となっていることからステップS904はYESとなる。これより、階層を変更することなく、ステップS906の処理を行うことになる。よって、ステップS906において3.1要件Bが上記アウトライン機能上の上記木構造ツリー構造における2階層目レベル2に出力される。以上、全ての項目について上記処理を実行したら、ユーザが文書5aの内容をワードプロセッサ例えばMicrosoftWordで編集できるようになり換言すれば、支援装置1を使用しなくても編集できるようになり、特に上記下位側文書として雛形が生成されている文書5aに対して、ユーザが任意の情報を入力することで、文書を完成させることができる。そして、上記の様にワードプロセッサ例えばMicrosoftWord上で完成させた文書を、文書入力部7によって元の形式に戻して文書格納部5に格納することになる。尚、この例に限らず、ユーザは、外部出力せずに支援装置1を使用して、文書5aの内容を編集して文書を完成させるようにしてもよい。尚、上記関連一覧表に関しても、上記のように外部出力した後、ユーザによる上記文書の編集内容例えば章の追加/削除等に合わせて、ユーザが適宜編集/修正等してもよい。以下、文書入力部7による処理について説明する。これについては、フローチャート図等を示すことなく説明するものとする。文書入力部7では、上記外部出力されたまたは出力後に編集などされた文書の取り込みを行う。主な用途としては、文書出力部6で出力した文書、一覧表等を外部で編集し、再び取り込むような場合が想定されるが、この例に限らない。これは、例えば上記図10の処理において階層とアウトラインレベルとを逆にしたような処理と見做してよい。すなわち、取り込み対象の文書が例えばワードのアウトライン機能による文書の場合には、各データ毎に見出しや本文等の種別が付与されると共に、見出しの場合には所謂アウトラインレベルによって階層管理されている。これより、見出しの場合にはアウトラインレベルによって階層を認識しながらデータをタイトル部31として取り込み、本文の場合にはデータを本文部32として取り込むようにしてもよい。但し、これだけでは不十分であり、リンク情報を生成する必要がある。すなわち、取り込みが完了した後に、関連一覧表の対応関係を参照して、取り込んだ文書とそれ以外の文書の対応関係を識別し、リンク情報を作り直す必要がある。例えば、設計書において上記外部で編集作業が行われた為に新たに4.1.1.4章が追加された場合、図6に示す旧リンク情報の代わりに、新たなリンク情報を生成する必要がある。この新たなリンク情報は、特に図示しないが、図6のリンク情報における3.1-3,4.1.1.3と3.2,4.1.2との間の行に新たに3.1-4,4.1.1.4が追加された内容となる。尚、この編集に伴って、上記外部出力された関連一覧表は、例えば編集作業者によって修正されているものとする。すなわち、図9の例においては要求仕様書における3.1に対しては、設計書における4.1.1.1、4.1.1.2、及び4.1.1.3が対応付けられていたが、更に、4.1.1.4も対応付けられるものとなる。上記関連一覧表からリンク情報を生成する処理を、上記要求仕様書と設計書を例にして説明するならば、まず、対応関係が1対1であるか否かを判定する。上記の例では、3.1に対して、4.1.1.1、4.1.1.2等が対応付けられているので、対応関係は1対1ではない1対複数であることになる。よって、この場合には、複数側4.1.1.1等は全てそのまま出力する。一方、単数側3.1は、所定のルールに従って例えば3.1-mm=1,2,3、を生成して、これらを上記複数側にそれぞれ対応付ける。これより、図6における3.1-1,4.1.1.1、3.1-2,4.1.1.2、3.1-3,4.1.1.3の部分が生成されると共に更に3.1-4,4.1.1.4が追加されることになる。更に、3.1自身に対しては、4.1.1.1、4.1.1.2等の1つ上の階層の章番号を対応付ける。章番号の規則性から考えて、当然、これら4.1.1.1等の1つ上の階層の章番号は4.1.1であるので、3.1に対しては4.1.1を対応付ける。これより、図6における3.1,4.1.1の部分が生成されることになる。その後は、要求仕様書と設計書の両方で更に1つ上の階層の章番号を上記章番号の規則性に従って生成して、相互に対応付ける処理を行っていく。3.1の1つ上は‘3’であり、4.1.1の1つ上は4.1となるので、これより図6における3,4.1の部分が生成されることになる。これを例えば最上位階層の対応付けを行うまで繰り返す。他も略同様にして生成できるので、上記関連一覧表から各リンク情報を生成できる。尚、上記文書入力部7による処理は、上述した一例に限らない。例えば、取り込み対象の文書が、上記アウトラインレベルのような階層情報や、見出しや本文等の種別が付与されていない文書であった場合、例えば下記のようにして文書と取り込むようにしてもよい。すなわち、例えば、取り込み対象の文書を順次スキャンし、タイトル部として識別できるデータの場合には、タイトル部31として取り込み、それ以外の場合には、本文部32として取り込む。例えば、先頭部分が数字である場合にはタイトル部であると判定すればよい但し、この場合、例えばユーザに対する本文部32の記述ルールとして最初の文字は数字以外とする等のルールを、予め設けておくことが望ましい。そして、任意のデータをタイトル部31として取り込む場合には、その先頭部分の数字313113111のような数字;章番号に応じて、階層を判定し、判定した階層のデータとして当該データを取り込む。階層の判定方法は、例えば章番号における‘.’の数に応じて、例えば階層=‘.’の数1等とすればよい。この場合、上記31は階層2311は階層33111は階層4と判定されることになり、また‘3’の場合には‘.’が1つもないので階層1と判定されることになる。尚、章番号は、所定の規則性1,2,3というように1から順番の番号となるがあるので、例えば階層2を例にすると、31、32、33の後が35等となることはあり得ないことになる。これより、上記データをタイトル部31として取り込む際に、上記規則性に従ったチェックを行い、この規則性に違反するような章番号上記3.3の後の3.5等が現れたときは、エラーを出力し、処理を中止するようにしてもよい。図11は、本例の要件管理支援装置1のディスプレイ装置12に表示される画面の例である。図示のように、画面50の上部には、主要な機能を実行するための命令ボタン群51が配置されているひな形生成、文書出力、文書取込、一覧表生成など。また、これら命令ボタン群51の下の領域52は、各文書のデータを切替え表示できるように、タブにより画面が切り替えられるようになっている。図では要求仕様書を表示させている状態を示している。尚、当然、単に表示させるだけでなく、ユーザが任意のデータを入力して文書を編集することもできる。更に図示のようにタブのなかには仕様書等の文書名だけでなく一覧表も示されており、これを選択すると上記図9などに示す関連一覧表が表示される。尚、文書の数は階層の数に応じて変更できる。図11に示す画面上でのユーザ操作例は、例えば下記の通りである。ユーザは、例えば最初に要求仕様書を記述する。これは、元になる文書がないので、直接図11の画面上で記入するか、もしくは、章構成を記述した外部ファイルとして作成し、文書取込ボタンを押して取り込む。上記のようにして要求仕様書を作成したら、次に、ひな形生成ボタンを押して、ひな形文書を自動生成させる。これは、ひな形生成ボタンを押すことで例えば図12に示すようなポップアップ画面が表示される。ユーザは、図12の画面上で、生成元文書、生成先文書や基点を任意に指定したうえで、生成ボタンを押すことで、生成先文書のひな形が自動的に生成されることになる。本例では、作成済みの文書は要求仕様書のみであるので、生成元文書は要求仕様書とする以外にないことになる。図示の例では、要求仕様書に基づいて設計書のひな形が自動的に生成されることになる。そして、設計書のひな形が自動生成された後、ユーザが上記図11の画面50において設計書タブを指定することで、上記領域52には設計書のひな形データが表示されることになる。ユーザは、このひな形に基づいて設計書を作成完成させることになる。すなわち、例えば、ひな形において、タイトル部31に関しては、章番号が付与されており、タイトルの記述も行われている生成元文書のコピーので、そのままで良ければそのままとし、そのままでは適当ではないと思うならば適宜修正を加えることになる。また、本文部32に関しては、上記の通り生成元文書のコピーが行われるが、これは特に必要なものではなく、基本的には必ずユーザによる記述が行われることになる。尚、本文部32の記述を行うときには、適宜、章の追加、削除を行いながら記述するものであってもよい。また、編集の際には、章の追加削除、文章の入力モードの切り替え本文入力/タイトル入力、タイトルの章の段を1つ上げる、1つ下げる、等といった命令群が、記述を行うためには必要であるが、これらは例えばキーボードからコマンド入力を行うことにより実現させればよい。あるいは、図11には示していないが、画面50上にこれらの命令に対応するボタンを配置しても良い。また、図11に示す画面50上では、3章のみ表示しているが、取り込み時には、3章以外の章も同時に取り込み、編集を行うことも可能である。図11の画面上では編集操作が煩雑な場合や、プリントアウトしたい場合には、文書を外部出力してから行う。外部で編集してから取り込みを行う場合には、一覧表を作成し、これも外部出力する。外部で章を追加削除した場合には、一覧表も同様に編集することにより、再度取り込みを行う場合にも矛盾なく取り込むことが可能となる。最後に、上記図9等に示した関連一覧表の生成処理について、図13のフローチャート図を参照して説明する。尚、関連一覧表の生成処理の一例は、既に説明してあり、ここでは他の例について説明する。図13に示す処理は、全ての文書を対象にして図9に示す例では6つの文書について任意の2つの文書間の関連を抽出して記憶する処理となるステップS500a-500b間でループする処理。これは、例えば、図6に示すような関連情報を参照して行うことになる。よって、この例でも図6に示すような関連情報リンク情報が存在する2つの文書が、処理対象となる。例えば、一例としては、要求仕様書と設計書とが対応付けられ図6に示す通り、要求仕様書と型式試験仕様書とが対応付けられ、設計書と詳細設計書とが対応付けられ、設計書と機能試験仕様書とが対応付けられ、詳細設計書と単体試験仕様書とが対応付けられるが、これらの例に限らない。まず、上記ステップS101と同様にユーザが任意の基点の指定を行うステップS501。そして、入力された基点から順に、各項目本例では章番号とするがこの例に限らないを順次処理対象としてステップS503~S505の処理ステップS502a-s502b間のループ処理を行うことになる。まず、処理対象項目が本文であるか否かを判定するステップS503。これは例えば、章番号が存在しない項目は本文であると判定する。あるいは図6に示すような関連情報を参照する場合、末尾が-番号となっている場合には、本文であると判定する。もし、処理対象項目が本文ではない場合にはステップS503,NO、この処理対象項目その章番号等を例えばメモリの所定領域に上書き記憶するステップS504。そして、ステップS502bにおいて全項目について処理済みか否かを判定して、未だであればステップS502aに戻り、次の項目を処理対象とする。一方、処理対象項目が本文である場合にはステップS503,YES、上記メモリの所定領域に記憶してある項目章番号等を読み出して、これを例えば上記図9等に示した関連一覧表の該当箇所に登録する。更に、この読み出した項目に対応する項目を、この該当箇所に対応付けて登録するステップS505。そして、上記ステップS502bへ移行する。ここで、例えば一例として要求仕様書と設計書を例にし要求仕様書と対応付け元、設計書を対応付け先とする、要求仕様書の‘3’3章が基点に指定されたものとする。この例では、最初の処理対象項目は‘3’であるので、ステップS503はNOとなり‘3’が上記所定領域に記憶される。次の処理対象項目は‘3.1’であるので、今度もステップS503はNOとなり‘3.1’が上記所定領域に記憶される。次の処理対象項目は‘3.1-1’であるので、今度はステップS503はYESとなり、ステップS505の処理が実行される。これは本例では上記所定領域に記憶されている‘3.1’が、関連一覧表の該当箇所本例では要求仕様書のフィールドに格納されると共に、現在の処理対象項目である‘3.1-1’に対応する設計書の項目は、図6の例から‘4.1.1.1’であることが分かるので、これを上記該当箇所に対応付けて本例では設計書のフィールドに格納される。これより、図9に示すように、要求仕様書の‘3.1’に設計書の‘4.1.1.1’が対応付けられて登録される。更に、次の処理対象項目は‘3.1-2’であるので、今度もステップS503はYESとなり、ステップS505の処理が実行されるが、上記所定領域の記憶内容に変化はないので‘3.1’が記憶されたままである、関連一覧表には図9に示すように、要求仕様書の‘3.1’に設計書の‘4.1.1.2’が対応付けられて登録されることになる。同様に、次の処理対象項目は‘3.1-3’であるので、今度もステップS503はYESとなり、ステップS505の処理が実行されるが、上記所定領域の記憶内容に変化はないので‘3.1’が記憶されたままである、関連一覧表には図9に示すように、要求仕様書の‘3.1’に設計書の‘4.1.1.3’が対応付けられて登録されることになる。次の処理対象項目は‘3.2’であるので、今度はステップS503がNOとなり、上記所定領域には‘3.2’が上書きされる。そして、次の処理対象項目は‘3.2-1’であるので、ステップS503はYESとなり、ステップS505の処理が実行される。このとき、上記所定領域には‘3.2’が記憶されているので、これより、関連一覧表には図9に示すように、要求仕様書の‘3.2’に設計書の‘4.1.2.1’が対応付けられて登録されることになる。更に、次の処理対象項目は‘3.2-2’であるので、今度もステップS503はYESとなり、ステップS505の処理が実行されるが、上記所定領域の記憶内容に変化はないので‘3.2’が記憶されたままである、関連一覧表には図9に示すように、要求仕様書の‘3.2’に設計書の‘4.1.2.2’が対応付けられて登録されることになる。尚、後に、関連一覧表において同一項目は1つにまとめるようにしてもよい。これより、図9に示すように、上記3つの‘3.1’は1つにまとめられて、この‘3.1’に対して設計書の‘4.1.1.1’、‘4.1.1.2’、‘4.1.1.3’が対応付けられて登録された状態となる。同様に、上記2つの‘3.2’は1つにまとめられて、この‘3.2’に対して設計書の‘4.1.2.1’、‘4.1.2.2’が対応付けられて登録された状態となる。尚、ユーザが処理開始前に処理対象の2つの文書の関係に応じたタイプ指定を行うことで、処理アルゴリズムが切り換わるようにしてもよい。例えば一例としては、処理対象の2つの文書の関係として、図5に示すようなタイプタイプAとすると、図8に示すようなタイプタイプBとするとがあるとした場合、ユーザがタイプAを指定すると上述した図13の処理が実行される。一方、ユーザがタイプBを指定した場合にも、基本的には上述した図13の処理が実行されるが、一部、アルゴリズムが異なる部分がある。すなわち、タイプBの場合、上記ステップS505において、もし対応付け先本例では設計書に登録すべき項目本例では章番号が無かった場合には、例えば直前の項目を出力するようにしてもよい。例えば図8に示す要求仕様書と型式試験仕様書の例の場合、要求仕様書の‘3.1-1’すなわち本文に対して型式試験仕様書側も本文となっているので、上記処理では関連一覧表において要求仕様書に関しては‘3.1’が登録されるが、型式試験仕様書にはこれに対応付けて登録すべき項目本例では章番号が無いことになる。この為、この場合には、直前の項目である‘2.1’を登録する。これより、図9に示すように、要求仕様書の‘3.1’に対して、型式試験仕様書は‘2.1’が登録されることになる。以上説明したように、本例の要件管理支援装置1では、上位側の文書の章構成で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、これを下位側文書のひな形として提供する。その際、関連情報が生成されて登録するようにしてもよい。文書作成者は、このひな形に詳細な設計情報を入力することにより、文書として完成させる。また、変更等があったときに対応関係を維持するために、上記関連情報を一覧表の形で自動的に生成して、記憶/出力するようにしてもよい。また、上記の文書や関連一覧表を、要件管理支援装置1の外部で、ワードプロセッサやエディタ、スプレッドシートなどで編集できるように、外部出力することもできる。その際、出力した文書には、文書構成の情報を付帯させ、文書の構成要素同士の関連は、関連一覧表で識別できるようにする。また、外部のワードプロセッサやエディタ、スプレッドシートなどで編集した、これらの文書や関連一覧表を要件管理支援装置に取り込み、データを維持するために、関連一覧表の情報を元に、文書の間の関連情報を自動的に生成するようにしてもよい。以上説明したように、本例の要件管理支援装置1によれば、上位側の文書の章構成で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、下位側文書のひな形として提供する。その際、上位側の文書の各項目と下位側の文書の各項目との関連情報文書間の対応関係を示す情報;リンク情報も、自動的に生成付与される。文書作成者は、このひな形に詳細な設計情報を入力することにより、文書として完成させる。また、文書内容に変更等があった場合でも文書間の対応関係を維持できるようにするために、上記関連情報を一覧表の形で、自動的に生成出力する。また、これらの文書や一覧表を、要件管理支援装置1の外部で、ワードプロセッサやエディタ、スプレッドシートなどで編集できるように、外部出力する。その際、出力した文書には、文書構成の情報階層等を付帯させる。更に、上記一覧表も一緒に出力して、文書の構成要素同士の関連は、一覧表で識別できるようにする。また、上記のように要件管理支援装置1の外部へ出力した文書を、ユーザがワードプロセッサやエディタ、スプレッドシートなどで任意に自由に編集した場合、編集後の文書に応じて一覧表も編集した後、これらの編集後の文書や一覧表を、再び要件管理支援装置1に取り込むようにしてもよい。その際、一覧表の情報を元に、文書の間の関連情報リンク情報を自動的に生成する。本例の要件管理支援装置1によれば、章番号が付与され相互に関連し得る複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできる。上記複数の文書を作成する際に、例えば1つの文書を作成すれば、他の文書に関しては、当該作成済みの文書に基づいてひな形を作成すると共にリンク付けも自動的に行われる。よって、他の文書に関しては、特に文書の新規作成時に、効率よく文書作成を行えると共に、他の文書との関連情報リンク情報により管理された文書が自動的に作成されることになる。特に章番号が付与される複数の文書であって相互に関連する複数の文書に関して、上位側の文書に基づいて下位側の文書の章番号やタイトル名等を自動的に付与することができ、また関連する章同士をリンク付けでき、以って変更があった場合にも効率的に維持管理することができる。更に、項目漏れ、リンク付け漏れ等のミスも防止できる。上記複数の文書がソフトウェアの設計に係る各種文書である場合には、正しいソフトウェアを効率良く製作することができるようになる。"