JP2013020437A - 要件管理支援装置 - Google Patents

Abstract

【課題】章番号が付与され相互に関連する複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできる。
【解決手段】各種文書５ａのうち上記上位側文書が上位側文書解析部２で解析され、この解析結果に基づいて下位側文書生成部３により下位側文書のひな形を自動生成する。この下位側文書のひな形は、上位側文書に基づいて各タイトルと共に章番号が自動的に生成されて成るものである。更に、関連情報生成部４により、文書間の関連情報を自動生成する。生成された下位側文書は文書格納部５に格納される。生成された関連情報も文書格納部５に格納される。
【選択図】図１

Description

本発明は、ソフトウェアの要件・仕様を効率的に管理し、文書を効率的に記述するための支援装置に関する。

高品質のソフトウェアを効率良く製作するための方法として、最初に、そのソフトウェアシステムに必要十分となる要件（要件項目）を定義し、各要件を段階的に詳細化していく方法がある。この方法では、例えば、詳細化の段階を３段階とし、要求仕様書、設計書、詳細設計書のように設計文書を展開する。

この場合、要求仕様書には、そのソフトウェアシステムに必要十分となる要件を定義する。また、設計書には、要求仕様書に記述された内容をもとに、要求項目を実現するため機能の集まりに分割し、その仕組みを設計する。また、詳細設計書には、設計書に分割して記述された内容をもとに、プログラムの実装形態に対応したレベルまで設計を分割・詳細化し、実装レベルでの設計を記述する。

例えば、特許文献１には、その図６に示されるような図形式の管理手段により、段階的に要件を詳細化することや、それにＴＡＢと呼ばれる属性を関連付けて、仕様を管理する技術が開示されている。

ところで、ソフトウェアを正しく製作するためには、下位側の文書は、上位側の文書に記述された内容について、もれなく、且つ、不必要なものを含まないように、作成する必要がある。そのため、上位側の文書と下位側の文書を関連付けて管理する方法が考案されている。

例えば特許文献２では、ソフトウェア成果物に設計情報のほかに設計情報識別ＩＤを設け、ソフトウェア成果物内の設計情報識別ＩＤ間の関連を、設計情報解析部を介して格納することにより、対応関係を管理する技術が開示されている。

また、特許文献５でも、不具合報告書・ソースコード・修正報告書・内部設計書・単体試験書間・外部設計書・要求仕様書間の関連により管理する技術が開示されている。
また、これらの文書間に求められる関係は、設計文書と試験仕様書の間にも同様に必要となる。例えば、上記のように詳細化の段階を３段階としているような場合には、要求仕様書に記述された各項目についての仕様の確認、設計書に記述された各項目についての設計項目の確認、詳細設計書の各項目に対応する実装項目の確認などを、もれなく、かつ不必要なものを含まないように、実施する必要がある。

例えば特許文献３では、ソースファイル（ソースコード）を基準に、ソースファイルに含まれる関数から試験項目を抽出し、対応した単体試験規格書を自動生成することにより、対応付けを適切に行う技術が開示されている。

このように、設計書間や、設計書と試験仕様書間を対応付けて管理することにより、項目もれを防ぎ、かつ、不必要な項目の混入を避けることができるので、ソフトウェアを正しく製作することができるが、そのためには、設計書間や、設計書と試験仕様書間を対応付けて管理する関連情報（リンク情報）が適正であることを効率よく確認する必要がある。

例えば、特許文献１では、設計情報間の関連を管理し、上流工程の設計情報が下流工程の設計情報へ展開されているかを確実に確認するための技術が開示されている。
しかしながら、このような管理を行うためには、各文書間の関連情報を逐次入力していく必要があり、作業工数が大きくなったり、人為ミスの混入の元となるなどの問題点がある。このような問題点は、特許文献４でも指摘されており、この文献には、リンクを張る時に、候補をキーワードで抽出し、リンクの省力化を図る技術が開示されている。

また、従来より、“要件管理システム（ツール）”または“要求管理システム(ツール）”等と呼ばれるシステム（ツール）が知られている。この様な要求／要件管理システムは、各要求（要件）間のリンクの設定の支援を行ったり、トレーサビリティを確保する為に利用されている。また、所謂“トレーサビリティ・マトリックス”の管理等も行われる。この様なシステム（ツール）の具体例としては、例えば、ＩＢＭ社（以前はテレロジック社）のＤＯＯＲＳ（Ｒａｔｉｏｎａｌ ＤＯＯＲＳ）（登録商標）や、ＩＢＭ社のRequisitePro（登録商標）等の製品が知られている。

上記製品化されている要件（要求）管理システムは、各仕様書の記述内容を１項目１レコードとしてデータベース化する機能、ＧＵＩからの操作により各要件（要求）間のリンクの設定を受け付ける機能、ある仕様書のある要件（要求）に対応する、他の仕様書の該当部分を検索・表示する機能等が備えられている。

そして、上記特許文献４に記載の通り、上記「ＧＵＩからの操作により各要件（要求）間のリンクの設定を受け付ける機能」に関しては、各仕様書の関連項目のリンクを手動で行わなければならない為、ユーザの負担が掛かるうえ、リンクミスを招き易いという問題点があった。この問題を解決する為、特許文献４では、リンク元の仕様書の要件（要求）に含まれるキーワードに基づいてリンク先候補を自動抽出している。

尚、上記各仕様書の一例が、上述した要求仕様書、設計書、詳細設計書等であるが、この例に限らない。

特開平６−２０２８５９号公報 特開２００７−１９９７５５号公報 特開２００３−１７７９４２号公報 特開２００８−１９２０５９号公報 特開２００２−１８２９０８号公報

このように、設計書間や、設計書と試験仕様書間を対応付けて管理することにより、項目もれを防ぎ、かつ、不必要な項目の混入を避ける技術により、ソフトウェアを正確に効率良く製作することができるが、これを効率よく実施することが必要となる。

例えば特許文献４で開示されている技術によると、既に、設計文書等が作成されていて、変更があったときには、この方法によって対応する箇所を効率よく発見し、関連情報の入力効率を向上させることが可能であったが、最初に文書を作成し、対応する文書がまだ作成されていない場合には、やはり、文書の入力後に、ひとつひとつキーワードにより検索して関連情報を入力していくという作業を免れることができない。

本発明の課題は、各々が章番号を有する文書であって相互に関連し得る複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできる要件管理支援装置等を提供することである。

本発明の要件管理支援装置は、各々が章番号を有する文書であって相互に関連し得る複数の文書の作成を支援する装置であって、任意の１以上の前記文書を任意に作成させる文書作成支援手段と、前記作成された文書の何れか１つを上位側文書とし、該上位側文書に基づいて、該上位側文書に関連する他の文書としての下位側文書のひな形を生成するひな形生成手段と、前記上位側文書の各項目と下位側文書のひな形の各項目との関連を示す関連情報を生成する関連情報生成手段とを有し、前記文書作成支援手段は、前記ひな形に基づく前記下位側文書の作成を支援する。

上記構成の要件管理支援装置において、例えば、前記ひな形生成手段は、前記上位側文書の章構成で規定される文書構成から前記下位側文書の章構成で規定される文書構成を導出することで、該下位側文書のひな形を生成する。

また、上記構成の要件管理支援装置において、例えば、前記ひな形生成手段は、任意に設定される基点となる章番号と前記上位側文書の章構成で規定される文書構成に基づいて、前記下位側文書の章番号、タイトル名を導出することで、該下位側文書のひな形を生成する。

上記要件管理支援装置によれば、各々が章番号を有する文書であって相互に関連し得る複数の文書のうち、少なくとも１つの文書を作成すれば、他の文書に関しては作成済みの文書に基づいてひな形が作成されると共に、文書間のリンク付け情報である関連情報が自動的に生成されるので、文書作成及びリンク付けに係るユーザの手間が、軽減できる。更に、項目漏れ、リンク付け漏れ等のミスも防止できる。

本発明の要件管理支援装置等によれば、各々が章番号を有する文書であって相互に関連し得る複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできるようになる。文書に変更があった場合にも効率的に維持管理することができる。

文書の新規作成時に、効率よく文書作成できると共に、文書間の対応付けデータを構築することができるようになり、より効率的に文書作成できると共に、項目もれの防止、不要な項目の排除を行うことができる。

本例の要件管理支援装置の機能構成図である。 本例の端末装置のハードウェア構成例を示す図である。 文書格納部に格納される文書の構成例を示す図である。 上位側文書と下位側文書と関連情報の関係を示す概念図である。 上位側文書と下位側文書と関連情報の具体例を示す図である。 関連情報（リンク情報）の具体例である。 下位側文書雛形生成処理のフローチャート図である。 上位側文書が要求仕様書であり、下位側文書が型式試験仕様書である場合の具体的なデータ構造例を示す 関連一覧表の具体例である。 アウトライン機能を使用して出力する場合の処理フローチャート図である。 要件管理支援装置の画面の例である。 ひな形作成画面の例である。 関連一覧表の生成処理フローチャート図である。

以下、図面を参照して本発明の実施の形態について説明する。
図１に、本例の要件管理支援装置１の機能構成図を示す。
図示の例の要件管理支援装置１は、上位側文書解析部２、下位側文書生成部３、関連情報生成部４、文書格納部５、文書出力部６、文書入力部７、関連情報解析部８等の各種機能部を有する。文書格納部５は、例えば各種文書５ａや関連情報５ｂ等を記憶する。

上記の要件管理支援装置１は、例えば、図２に示すような汎用的な電子計算機の端末（パソコン）１０上に構築することができる。
図２に示すパソコン１０は、主記憶装置１１、ディスプレイ装置１２、補助記憶装置１３、入力装置１４、演算装置１６等を有し、これらが内部バス１５に接続されて相互にデータ送受信等できるようになっている。

主記憶装置１１は例えばメモリ等である。補助記憶装置１３は例えばハードディスク等であり、予め所定のアプリケーションプログラムが記憶されている。演算装置１６は、例えばＣＰＵ／ＭＰＵ等であり、上記アプリケーションプログラムを読出し・実行することにより、上記図１に示す各種機能部（上位側文書解析部２、下位側文書生成部３、関連情報生成部４、文書出力部６、文書入力部７、関連情報解析部８等）の機能を実現するものである。尚、上記文書格納部５が、補助記憶装置１５に相当するものと考えても良い。つまり、例えば補助記憶装置１５には上記各種文書５ａや関連情報５ｂが記憶されるものであってよい。但し、この例に限らない。

ディスプレイ装置１２は例えば液晶ディスプレイ等あり、入力装置１４は例えばキーボード、マウス等であるが、これらの例に限らない。
文書格納部５に格納される各種文書５ａは、例えば上記従来技術で説明した要求仕様書、設計書、詳細設計書のような各種設計文書である。これは、典型例としては、上記のように相対的に上位側の文書、下位側の文書の関係があるものであるが、この典型例に限るものではない。また、設計文書は一例であり、この例に限るものではない。また、本手法の適用対象となる各種文書５ａは、章番号を有するものであることを前提とする。

上記のことから、各種文書５ａは、例えば、各々が章番号を有する文書であって相互に関連し得る複数の文書であると言うことができる。尚、章番号とは、例えば章／節／項番号等を意味するものとするが、この例に限らない。ここでは、例えば、Ａ，Ｂ，Ｃ，・・・等のように数字が含まれないものや、Ａ１，Ａ２，Ａ３，・・・等のように記号と数字が混在するものであっても、“章番号”であるものとする（但し、章番号を自動的に生成・付与する為に、何らかの規則性を有することが必要である）。

また、尚、本説明における上位側文書、下位側文書とは、上記各種設計文書における上記相対的に上位側の文書、下位側の文書を意味することが典型例となるが、この例に限らず、例えば“上位側文書に基づいて下位側文書のひな形が生成される”ものであれば何でもよいと考えても良い。

上記各種文書５ａのうち上記上位側文書が上位側文書解析部２で解析され、この解析結果に基づいて下位側文書生成部３により下位側文書のひな形を自動生成する。この下位側文書のひな形は、上位側文書に基づいて各タイトルと共に章番号が自動的に生成されて成るものである。更に、関連情報生成部４により、文書間の関連情報（任意の２つの文書の各項目間のリンク情報等）を自動生成する。生成された下位側文書は文書格納部５に格納される。生成された関連情報（リンク情報等）も文書格納部５に格納される。

本例の要件管理支援装置１では、上位側の文書の章構成（章／節／項構成等）で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、下位側文書のひな形として提供する。文書作成者は、このひな形に例えば詳細な設計情報等を任意に入力することにより、文書として完成させる。

また、上記関連情報生成部４によって、任意の２つの文書間の（たとえば上位側文書と下位側文書との）関連情報５ｂが、生成されて登録される。関連情報５ｂの具体例は図６に示し後に説明する。

また、例えば文書に変更等があったときに対応関係を維持するために、この関連情報５ｂを一覧表の形で生成して出力することもできる。すなわち、関連情報解析部８は、文書格納部５に格納された文書５ａや関連情報５ｂ等に基づいて、各文書の（各項目毎の）関連を示す一覧表を自動的に生成し、この関連一覧表を文書格納部５に格納する。関連一覧表の具体例を図９に示し、後に説明する。

また、文書出力部６は、上記の各種文書５ａや関連一覧表等を、要件管理支援装置１の外部でワードプロセッサやエディタ、スプレッドシートなどで編集できる形式に変換して、外部出力する。尚、関連一覧表は、そのまま外部出力しても構わない。

ここで、要件管理支援装置１内の文書形式は、例えばＤｏｏｒｓ（ＩＢＭ社製）等のような要件（要求）管理ツールによるものである。要件（要求）管理ツールで管理する文書は、例えば、各文書間のリンク（文書の各関連項目間のリンク）が設けられているものである。また、各文書の項目はセル単位で管理されているものである。

勿論、Ｄｏｏｒｓ（ＩＢＭ社製）は要件（要求）管理ツールの一例であり、この例に限らない。一般に、要件（要求）管理ツールによって、相互に関連する複数の文書が管理されるものであり、特に上記各文書間のリンク（文書の各関連項目間のリンク）と章番号の管理（トレーサビリティを確保すること）が重要となる。

また、外部のワードプロセッサは例えばＷＯＲＤ（ワード；マイクロソフト社製）であるが、この例に限らない。上記外部出力処理は、例えば文書出力部６が行ってよいが、この例に限らない。文書出力部６は、例えば単に各種文書５ａを変換なしで外部出力するものであってもよい。

尚、出力した文書には、文書構成の情報（例えば階層／レベル、タイトルか本文か等）を付帯させるようにしてもよい。各文書の構成要素（項目）同士の関連は、関連一覧表で識別できるようにすればよい。

また、上記外部のワードプロセッサやエディタ、スプレッドシートなどで編集後の各種文書や関連一覧表を、文書入力部７を介して要件管理支援装置１内に取り込むようにしてもよい。その際、関連一覧表の情報を元に、文書の間の関連情報（リンク情報）を自動的に生成する。

図３に、文書格納部５に格納される文書５ａの構成例を示す。
図示の例では、文書５ａは、章番号（章／節／項番号等）を持つタイトル部３１と、章番号を持たず、その親になるタイトルの内容を説明する本文部３２から成る。本文部３２は、タイトル部３１ひとつに対して、複数個あっても良い。また、タイトル部３１の下位にタイトル部３１があってよく、更にタイトル部３１の下位に複数のタイトル部３１があっても良い。すなわち、タイトル部３１は、例えば“章／節／項”等の「見出し」に相当し、典型例としては、章の下位に節があり、節の下位に項がある（逆に言えば、項の上位に節があり、節の上位に章がある）。当然、任意の章の下に複数の節があってよく、同様に、任意の節の下に複数の項があってよい。

図示の例では、例えば「３ 開発要件」が章に相当し、‘３’が章番号、“開発要件”が章の見出し（タイトル）に相当する。また、例えば、「３．１ 要件Ａ」や「３．２ 要件Ｂ」が節に相当し、‘３．１’や‘３．２’が節番号、“要件Ａ”や“要件Ｂ”が節の見出し（タイトル）に相当する。

但し、ここでは、節や項等を用いることなく、全てを章として説明する。よって、ここでは、‘３．１’や‘３．２’も章番号であるものとして説明する。従って“要件Ａ”や“要件Ｂ”も章の見出し（タイトル）に相当するものとして説明する。但し、「３．１ 要件Ａ」や「３．２ 要件Ｂ」は、「３ 開発要件」とは階層が異なる。

すなわち、タイトル部３１や本文部３２は、階層構造（ツリー構造）で管理されており、図３に示す例では、「３ 開発要件」が最上位階層（例えば階層１）であり、その下の階層（例えば階層２）に「３．１ 要件Ａ」や「３．２ 要件Ｂ」があり、更にその下の階層に本文部３２がある階層構造となっている。

図４は、関連情報生成部４により関連付けを行った上位側文書と下位側文書と関連情報の関係を示す概念図である。上位側文書２１と下位側文書２２の間は、それぞれの関連する項目（図３のタイトル部３１や本文部３２）が、関連情報２３(５ｂ)により対応付けられている。

図５に、上位側文書と下位側文書と関連情報の具体例を示す。
図５に示す例では、上位側文書が要求仕様書であり、下位側文書が設計書である（それぞれ、その一部のみを示す）。また、図５では関連情報を矢印で示すが、実際のデータ例は例えば図６に示すようになる。

図５の例の場合、要求仕様書に記述された内容が、より詳細化されて、設計書に記述されている。
図５では、上位側文書の構造が左側に示されている。また、下位側文書の構造が右側に示されている。また、図５や後述する図８等では矢印で示す、２つの文書の各項目間の対応付けを行っている情報が、関連情報５ｂである。

尚、各文書は、例えばセル単位で管理されている。図５等において各矩形が１つのセルを意味しているものとする。例えば図示の「３．開発要件」、「３．１ 要件Ａ」、「要件Ａの構成１」、「4.1.1 要件Ａ」、「要件Ｂの構成２の設計１」等を囲う各矩形が、それぞれ、１つのセルを意味している。各セルにそれぞれユニークな識別ＩＤを割当てて管理するようにしてもよい。

尚、本装置１では、例えば上位側文書（要求仕様書）に基づいて下位側文書（設計書）の雛形を自動生成するが、図５において図上右側に示す設計書の例は、この様な雛形に基づいてユーザが任意のデータを入力した状態を示している。例えば、図示の「要件Ａの構成１の設計１」等の本文部３２の記述は、ユーザが任意に入力したものである。

一方、「４．１．１ 要件Ａ」や「4.1.1.1 要件Ａの構成１」等のタイトル部３１の内容（章番号やタイトル名）は、要求仕様書に基づいて自動的に生成されたものである（上記雛形の段階で既に存在していた）。但し、タイトル部３１に関しては（特にタイトル名に関しては）、上記自動生成されたものをそのまま用いる例に限るものではなく、例えば自動的に生成されたものをユーザが任意に修正／変更してもよいし、自動生成を行わずにユーザが任意に入力するようにしてもよい。

尚、要求仕様書のデータ構造は図３で説明した通りであるが、設計書も略同様であると考えてよく、これより図示のようにタイトル部には符号３１を付してあり、本文部には符号３２を付してある。これは、後述する図８等に関しても同様である。

上記雛形の自動生成処理については、後に図７等を参照して説明する。
図５の要求仕様書では、３章（開発要件の章）に、設計書にてより詳細に設計される開発要件が記述されている。すなわち、３章を基点として、設計書にてより詳細に設計される開発要件が記述されている。

３章には、３．１章、３．２章の２つの要求項目が記述されている。また、３．１章の要求項目には、本文３２として、３項目の説明が記述されている。また、３．２章の要求項目には、本文３２として、２項目の説明が記述されている。

要求仕様書には、３章の前後にも、３章以外の章が含まれる（たとえば、文書の概要や、参照している規格などを１章、２章に記述したりする。）が、図５では、割愛している。なお、設計書においても、４．１章の前後にも他の章が存在するが、図５では割愛している。

一方、図５の設計書では、基点となる４．１章（設計の章）に、要求仕様書で記述された要求項目を受けて、より詳細に設計した内容（設計項目）が記述されているが、要求項目に記述された項目を過不足なく設計で実現するために、章構成を対応させている。

すなわち、４．１．１章で要求仕様書の３．１章の内容を、４．１．２章で要求仕様書の３．２章の内容を受けている。さらに、４．１．１．１章では、要求仕様書の３．１章の本文部３２の第１項目で記述された要件項目“要件Ａの構成１”を受けて、設計項目のタイトルとして“要件Ａの構成１”が記述されている。このような対応関係を図５では矢印で示しており、関連情報５ｂは、この対応関係を保持している。

そして、例えば上記設計項目“要件Ａの構成１”のより詳細な説明として、図示の例では２項目の本文部３２（設計内容）が記述されている。つまり、基本的には、階層構造となっているタイトル部３１において最下層のタイトル（章）について、１項目以上の本文部３２が記述されている。

ここで、上記関連情報５ｂは、具体的には例えば図６に示すようなデータとして、図５では矢印で示す上記２つの文書の各項目間の対応関係を保持している。
図６に示す例では、タイトル部３１に関しては章番号同士を対応付けている。図５の例では例えば要求仕様書の３．１章に対しては設計書の４．１．１章が対応するので、図６に示す例では「3.1，4.1.1」となっている。

また、図６に示す例では、上位側文書（要求仕様書）の本文部３２と下位側文書（設計書）のタイトル部３１とが対応付けられる場合には、本文部３２に付与する識別番号と、下位側文書のタイトル部３１の章番号とを、対応付けている。本文部３２に付与する識別番号は、例えば一例としては、本文部３２が属する上記最下層の章の章番号に、予め決められた所定のルールに従って記号、番号等を付与するものである。

図示の例では、上記最下層の章の章番号に“−ｍ”（ｍ＝１，２，３・・）を付与するルールとしている。よって、図示のように、例えば上位側文書（要求仕様書）の３．１章に属する３つの本文部３２については、順に、識別番号３．１−１、３．１−２、３．１−３が割り当てられており、これら各識別番号に対して下位側文書（設計書）の各章番号（4.1.1.1、4.1.1.2、4.1.1.3）が対応付けられている。

本例の要件管理支援装置１では、既に述べたように上位側文書に基づいて下位側文書の雛形を生成する。ここでは、図５のデータ構造を例に、その処理動作を説明する。この処理動作（下位側文書雛形生成処理）は、上位側文書解析部２と下位側文書生成部３によって実行される。

図７に、上記下位側文書雛形生成処理のフローチャート図を示す。
この処理は、上位側の文書の章構成で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、これを下位側文書のひな形とする処理であると言える。
更に言うならば、図７の処理は、（上位側と下位側の両方に関して）任意に設定される基点となる章番号と、上位側文書の章構成で規定される文書構成とに基づいて、下位側文書の章番号、タイトル名を導出することで、下位側文書のひな形を生成するものであるということも出来る。

図７の処理では、まず最初にユーザに任意の指定を行わせる。例えば図１２に示す例のように、ユーザに、生成元文書、生成先文書を任意に指定させると共に、各文書について基点となる章の章番号等を任意に指定させる（ステップＳ１０１）。図示の例では、生成元文書として要求仕様書が指定され、生成先文書として設計書が指定されている。更に、要求仕様書と設計書それぞれの基点となる章を指定させる。図１２の例の場合、要求仕様書の基点は３章、設計書の基点は４．１章である。

尚、既に述べたが、上記のように上位側文書、下位側文書を、単に、生成元文書、生成先文書と見做しても構わない。
そして、ユーザが例えば図１２に示す「生成」ボタンを操作することで、ステップＳ１０２以降の処理を開始する。すなわち、本例では要求仕様書の基点の直下の全ての章について、以下のループ処理を行う（ステップＳ１０２）。本例では、直下の全ての章とは、３．１章、３．２章を意味する。直下の各章を順次処理対象項目とし、処理対象とした項目について以下の処理を行う。

すなわち、まず、要求仕様書における処理対象の項目に対応する設計書の項目を生成する（ステップＳ１０３）。これは、本例では、要求仕様書の項目が、タイトル部３１であっても、本文部３２であっても、設計書側にはタイトル部３１として生成する（章番号とタイトルを生成する）（但し、この例に限らない）。章番号に関しては、処理対象の章番号が３．１章であったならば、これは基点である３章＋「．１」であるので、設計書における基点である４．１章＋「．１」＝4.1.1章を生成する。また、タイトルは、そのままコピーする。図示の例では、３．１章のタイトルは「要件Ａ」であるので、４．１．１章のタイトルも「要件Ａ」となっている。

上記のように、設計書側にタイトル部３１を生成した後、要求仕様書の各項目と、設計書の項目との間の対応関係（各項目間のリンク情報）を生成する（ステップＳ１０４）。これは、上記ステップＳ１０３で設計書の各項目（セル）を生成した際に、その生成元となった要求仕様書の項目（セル）は分かっているので、これを記憶しておく。そして、これら相互に対応するセル同士で、例えば各々の章番号同士を対応付ければよい。上記の例では、３．１章と４．１．１章とが対応付けられる。これより、図６に示す「3.1，4.1.1」の部分が生成されることになる。但し、これは、要求仕様書の項目がタイトル部３１であった場合である。要求仕様書の項目が本文部３２であった場合には、各本文部３２に識別番号を付与したうえで設計書の章番号と対応付ける。既に述べた例のように、本文部３２に例えば識別番号３．１−１等が割り当てられた場合には、図６に示すように例えば「3.1-1，4.1.1.1」などの対応付けが行われることになる。

そして、処理対象の項目に子要素（直下の項目）があるか否かを判定する（ステップＳ１０５）。図５の例では、「3.1 要件Ａ」に関しては３つの子要素（例えば“要件Ａの構成１”等）があり、「3.2 要件Ｂ」に関しては２つの子要素がある。

処理対象の項目に子要素がある場合には（ステップＳ１０５，ＹＥＳ）、本処理（図７の処理）を再帰的に呼び出す（ステップＳ１０６）。再帰的に呼び出されたときには、そのときの処理対象項目が、基点の項目となる。

従って、例えば処理対象項目が「3.1 要件Ａ」であった場合には、上記直下の項目は“要件Ａの構成１”、“要件Ａの構成２”、“要件Ａの構成３”の３つとなり、それぞれについて上記ステップＳ１０３、Ｓ１０４の処理が実行されることになる。

まずステップＳ１０３に関しては、“要件Ａの構成１”等は、タイトル部３１ではなく本文部３２であるので、章番号が無い。この為、例えば処理対象項目の章番号（ここでは３．１）を用いて例えば“−ｍ”（ｍ；１，２，３、・・・等）を付加することで識別番号“３．１−ｍ”を生成する。これより、上記“要件Ａの構成１”に対しては３．１−１、“要件Ａの構成２”に対しては３．１−２、“要件Ａの構成３”に対しては３．１−３が、それぞれ識別番号として割り当てられることになる。

また、上記設計書側にタイトル部３１を生成する処理では、上記の例では４．１．１章が生成済みであるので、その直下の章として４．１．１．ｍ章（（ｍ；１，２，３、・・・等）を生成する。

そして、上記ステップＳ１０４の処理を行うことで、例えば図５において矢印で示す対応関係が生成される。これは、関連情報（リンク情報）２３（５ｂ）としては図６に示す「3.1-1，4.1.1.1」、「3.1-2，4.1.1.2」「3.1-3，4.1.1.3」の部分が生成されることになる。尚、関連情報２３（５ｂ）の生成は、上記関連情報生成部４が実行するものであり、生成した関連情報２３（５ｂ）は上記文書格納部５に格納される。また尚、下位側文書のタイトル部３１におけるタイトル名は、上記の通り、上位側文書の処理対象項目のタイトル名を、そのままコピーする。よって、図５に示す例では、例えば“要件Ａの構成１”に対しては、“4.1.1.1 要件Ａの構成１”が生成されることになる。

尚、上記“要件Ａの構成１”等には子要素はないので、ステップＳ１０５の判定はＮＯとなる。
上記“要件Ａの構成１”等の各子要素に関する処理が完了したら、再帰的に呼び出した処理から復帰する。そして、上記基点の直下の項目のなかで未処理の項目が残っているならば、これを処理対象として上記ステップＳ１０３〜Ｓ１０６の処理を行う。未処理の項目が無いならば（要求仕様書の基点の直下の全ての章について上記処理が行われたならば）、ループを抜けて、本処理を終了する。

このように、ひな形を生成するが、上記処理例では上記の通り要求仕様書の項目がタイトル部３１であるか本文部３２であるかに係わらず、設計書側にはタイトル部３１として生成する。従って、ひな形生成直後には、設計書には、本文部３２が無いものが作成される。本文部３２は、設計書の作成者が後に任意に作成・追加する。従って、図５に示す設計書における各本文部３２（章番号が無い項目）は、ひな形生成後にユーザが任意に追加入力したものであり、ひな形には存在しなかったものである。

次に、図８に、上位側文書が要求仕様書であり、下位側文書が型式試験仕様書である場合の具体的なデータ構造例を示す。
この場合、要求仕様書に記述された内容に対応する試験項目が、型式試験仕様書に記述されている。図５の場合と異なり、図８の場合は、対応する要求仕様書などに記述された項目が過不足なく型式試験仕様書に記述されていることが重要であるため、図５のような階層の深化はおこらず、同じ階層での対応となっている。

図８の例の場合も、上位側文書から下位側文書を生成する処理は、図７とほぼ同様であるが、図８の例の場合には階層が深化しないので、要求仕様書の処理対象項目がタイトル部３１であった場合には型式試験仕様書側にはタイトル部３１として生成するが（つまり、図７と同じである）、要求仕様書の処理対象項目が本文部３２であった場合には、型式試験仕様書には本文部３２を生成するものであり、この点で多少異なる。

尚、階層を深化させるか否かは、例えば予めユーザが図７の処理開始前に指定するものであってよいが、この例に限らない。
図８の例では、例えば要求仕様書におけるタイトル部３１の一例である「３．１ 要件Ａ」に対応して、設計書におけるタイトル部３１「２．１ 要件Ａ」が生成される。但し、既に述べたように、タイトル部３１に関しては（特にタイトル名に関しては）、上記自動生成されたものをそのまま用いる例に限るものではなく、例えば自動的に生成されたものをユーザが任意に修正／変更してもよいし、自動生成を行わずにユーザが任意に入力するようにしてもよい。

また、例えば要求仕様書における本文部３２の一例である「要件Ａの構成１」に対応して、設計書における本文部３２「要件Ａの構成１」が生成される。但し、図８には、更にユーザが任意の文章を追加入力した後の状態を示している。すなわち、上記「要件Ａの構成１」にユーザが「について試験する。」を追加入力したことで、設計書における本文部３２として図示のように「要件Ａの構成１について試験する。」となっている。

そして、図７で説明した図５の例の場合と同様に、生成元となった要求仕様書と生成先となった型式試験仕様書の各項目との対応関係を、関連情報（リンク情報）２３（５ｂ）として記憶しておく。

以上、上位側文書解析部２と下位側文書生成部３によって実行される、下位側文書雛形生成処理と、これに伴う関連情報生成部４による関連情報５ｂの生成・格納処理について説明した。

以下、他の機能部による処理について説明する。
関連情報解析部８では、文書格納部５に格納された文書５ａや関連情報５ｂ等に基づいて、上記各種文書（要求仕様書、設計書、詳細設計書、型式試験仕様書等）間の関連を示す一覧表を自動的に生成し、この関連一覧表を文書格納部５に格納する。

図９に、文書格納部５に格納される関連一覧表の一例を示す。
図示の関連一覧表は、文書識別部４１と章構成対応部４２から成り、各種文書間の対応関係（その各項目間の対応関係）を章番号で示している。この例では、要求仕様書を詳細化したものが設計書であり、設計書を詳細化したものが詳細設計書である。また、要求仕様書に型式試験仕様書が対応しており、設計書に機能試験仕様書が対応しており、詳細設計書に単体試験仕様書が対応している。

図９に示すような関連一覧表の生成処理は、例えば上記下位側文書雛形生成処理の際に生成された上記図６等の関連情報５ｂに基づいて、２つの文書間の対応関係（その各項目間の対応関係）を生成する処理を、繰り返し行うものである。図６の例を用いて説明するならば、この例の場合には図９に示す関連一覧表のうち要求仕様書と設計書との対応関係が生成されることになる。

この処理は、特に図示しないが、図６に示す例のような関連情報５ｂを参照して、各行毎に、カンマ（，）の左側が要求仕様書の章番号、右側が設計書の章番号と判断する。そして、カンマ（，）の左側のデータを図９の関連一覧表の文書識別部４１が「要求仕様書」の列における章構成対応部４２に格納する。同様に、カンマ（，）の右側のデータを図９の関連一覧表の文書識別部４１が「設計書」の列における章構成対応部４２に格納する。

但し、本例では、ハイフン（−）以降は章番号として認識しないものとする。従って、例えば、３．１−１や３．１−２等は全て３．１として扱うものとする。これより、図９に示す例では、設計書における4.1.1.1章〜4.1.1.3章に対応する要求仕様書の章番号は、全て３．１章となっている。

他も同様にして、例えば設計書を上位側文書として下位側文書（例えば詳細設計書）の雛形が作成された場合には、設計書の各項目と詳細設計書の各項目との対応関係を示す関連情報５ｂが生成・格納されるので、これを参照して図９に示す例における設計書と詳細設計書の各章番号の対応関係部分が生成されることになる。この例では、例えば、設計書の4.1.1.1章に対して、詳細設計書の5.1.1.1章と5.1.1.2章が対応付けられている。

次に、文書出力部６の処理について説明する。
文書出力部６では、文書格納部５に格納された文書５ｂや上記関連一覧表等を外部出力する。

文書を出力するときには、出力先の文書形式（テキストやワードプロセッサ等）に応じた変換を行うが、図３のように文書が構成されているため、章番号を持つタイトル部３１と、章番号を持たず内容を説明する本文部３２とが、区別できるように出力する。更に、図３に示すような階層構造を保ちながら、外部出力する。換言すれば、文書出力部６は、上記章構成で規定される文書構成の各種文書５ｂを、その文書構成を保ちながら外部の任意の文書形式に応じて外部出力するものであると言える。

「区別できるように出力する」とは、例えば、テキスト形式で出力する場合には、各行毎に、その先頭に“3.1.1”のように数字（章番号）が記載されている場合にタイトル部３１と識別するというような方法を指す。

上記のように要件管理支援装置１内の文書形式は例えばＤｏｏｒｓ（ＩＢＭ社製）などによるものであるが、文書出力部６で外部出力する際には外部で編集等が行えるように形式変換して出力する。例えば、テキストエディタで編集できるようにするには、テキスト形式で出力する。

また、例えば、ワードプロセッサで編集できるようにする場合には、章のデータ構造を木構造データとして管理するアウトライン機能で管理できる場合には、章のタイトル部３１はアウトライン機能上の章（見出し）、本文部３２はアウトライン機能上の本文として出力しても良い。例えば、Microsoft社製の Microsoft Word はアウトライン機能を備えている。

アウトライン機能に対応させて出力する例の場合の処理フローチャート図を、図１０に示す。
尚、関連一覧表を出力する場合には、ワードプロセッサ、もしくは、スプレッドシートに表形式で出力する。これは、図９の形式のまま、そのまま出力すれば良い。

以下、図３の例を参照しながら図１０の処理について説明する。
まず、ユーザが、基点となる章番号を任意に指定する（ステップＳ９００）。本例では、例えば３章が指定されたものとする。但し、文書属性として基点となる章の番号を保持している場合には、この処理は不要である。

更に、出力先における階層を示す変数である「階層」を初期化する（ステップＳ９０１）。ここでは、例えば「階層」＝０とする。例えば、出力先がワードであって且つアウトライン機能に対応させる場合には、この「階層」は所謂“アウトラインレベル”に相当することになる。

そして、処理対象となる文書５ａを１項目（１セル；図３等で矩形枠で囲っている単位）ずつ参照して、ステップＳ９０３〜Ｓ９０７の処理を行う（ステップＳ９０２）。全ての項目についてステップＳ９０３〜Ｓ９０７の処理を実行したら、本処理を終了する。尚、本例では処理対象文書５ａは設計仕様書であり、図３の内容であるものとする。

まず最初は、上記基点となる項目（３章；３ 開発要件）が処理対象項目となり、その階層は‘１’であるものとする。そして、処理対象項目がタイトル部３１であるか否かを判定する（ステップＳ９０３）。上記例（３ 開発要件）は当然タイトル部３１であるので（ステップＳ９０３，ＹＥＳ）、ステップＳ９０４へ進む。尚、処理対象項目が例えば図３に示す「要件Ａの構成１」等のような本文部３２であった場合には、ステップＳ９０３の判定はＮＯとなり、ステップＳ９０７へ進む。

ステップＳ９０３がＹＥＳの場合には、まず、同じ階層か否かを判定する（ステップＳ９０４）。これは、現在の階層が上記変数としての「階層」と同じか否かを判定するものであり、ここではステップＳ９０１の処理により変数「階層」＝０である一方で、上記の通り現在の階層は‘１’（１階層目）であるので、ステップＳ９０４の判定はＮＯとなり、階層の変更を行う（ステップＳ９０５）。すなわち、変数としての「階層」を、現在の階層とする。よって、ここでは変数「階層」＝１とする。そして、現在の変数「階層」に応じたタイトルの出力を行う（ステップＳ９０６）（この場合は処理対象項目はタイトル部３１であるのでタイトル名が出力される）。つまり、上記「３ 開発要件」が上記アウトライン機能上の上記木構造（ツリー構造）における１階層目（レベル１）に出力される。換言すれば、“アウトラインレベル”＝“レベル１”を付加して“見出し”として「３ 開発要件」を出力する。

以上で最初の項目についての出力処理が完了し、以降、他の項目についても順次略同様の処理によって外部への出力（上記アウトライン機能上の上記木構造（ツリー構造）に対応する出力）を行う。

図３の例では、上記「３ 開発要件」の次の項目は、２階層目にある「３．１ 要件Ａ」であるので、上記ステップＳ９０３がＹＥＳ、ステップＳ９０４がＮＯとなり、ステップＳ９０５において変数「階層」＝２となる。これより、ステップＳ９０６において「３．１ 要件Ａ」が上記アウトライン機能上の上記木構造（ツリー構造）における２階層目（レベル２）に出力される。換言すれば、“アウトラインレベル”＝“レベル２”を付加して“見出し”として「３．１ 要件Ａ」を出力する。

続いて、次の項目が「要件Ａの構成１」であり、これは本文部３２であるので、ステップＳ９０３はＮＯとなり、ステップＳ９０７によって本文部３２（要件Ａの構成１）がアウトライン機能上の“本文”として出力される。次とその次の項目である「要件Ａの構成２」、「要件Ａの構成３」に関しても、略同様に、ステップＳ９０７によってアウトライン機能上の“本文”として出力される。

そして、さらに次の項目が２階層目にある「３．１ 要件Ｂ」であるので、上記ステップＳ９０３はＹＥＳとなり、更に現状では変数「階層」＝２となっていることからステップＳ９０４はＹＥＳとなる。これより、階層を変更することなく、ステップＳ９０６の処理を行うことになる。よって、ステップＳ９０６において「３．１ 要件Ｂ」が上記アウトライン機能上の上記木構造（ツリー構造）における２階層目（レベル２）に出力される。

以上、全ての項目について上記処理を実行したら、ユーザが文書５ａの内容をワードプロセッサ（例えばMicrosoft Word）で編集できるようになり（換言すれば、支援装置１を使用しなくても編集できるようになり）、特に上記下位側文書として雛形が生成されている文書５ａに対して、ユーザが任意の情報を入力することで、文書を完成させることができる。

そして、上記の様にワードプロセッサ（例えばMicrosoft Word）上で完成させた文書を、文書入力部７によって元の形式に戻して文書格納部５に格納することになる。
尚、この例に限らず、ユーザは、（外部出力せずに）支援装置１を使用して、文書５ａの内容を編集して文書を完成させるようにしてもよい。

尚、上記関連一覧表に関しても、上記のように外部出力した後、ユーザによる上記文書の編集内容（例えば章の追加／削除等）に合わせて、ユーザが適宜編集／修正等してもよい。

以下、文書入力部７による処理について説明する。
これについては、フローチャート図等を示すことなく説明するものとする。
文書入力部７では、上記外部出力された（または出力後に編集などされた）文書の取り込みを行う。主な用途としては、文書出力部６で出力した文書、一覧表等を外部で編集し、再び取り込むような場合が想定されるが、この例に限らない。

これは、例えば上記図１０の処理において「階層」と「アウトラインレベル」とを逆にしたような処理と見做してよい。
すなわち、取り込み対象の文書が例えばワードのアウトライン機能による文書の場合には、各データ毎に“見出し”や“本文”等の種別が付与されると共に、“見出し”の場合には所謂“アウトラインレベル”によって階層管理されている。これより、“見出し”の場合には“アウトラインレベル”によって階層を認識しながらデータをタイトル部３１として取り込み、“本文”の場合にはデータを本文部３２として取り込むようにしてもよい。

但し、これだけでは不十分であり、リンク情報を生成する必要がある。すなわち、取り込みが完了した後に、関連一覧表の対応関係を参照して、取り込んだ文書とそれ以外の文書の対応関係を識別し、リンク情報を作り直す必要がある。

例えば、「設計書」において上記外部で編集作業が行われた為に新たに「４．１．１．４」章が追加された場合、図６に示す旧リンク情報の代わりに、新たなリンク情報を生成する必要がある。この新たなリンク情報は、特に図示しないが、図６のリンク情報における「３．１−３，４．１．１．３」と「３．２，４．１．２」との間の行に新たに「３．１−４，４．１．１．４」が追加された内容となる。

尚、この編集に伴って、上記外部出力された関連一覧表は、例えば編集作業者によって修正されているものとする。すなわち、図９の例においては「要求仕様書」における“３．１”に対しては、「設計書」における「４．１．１．１」、「４．１．１．２」、及び「４．１．１．３」が対応付けられていたが、更に、「４．１．１．４」も対応付けられるものとなる。

上記関連一覧表からリンク情報を生成する処理を、上記「要求仕様書」と「設計書」を例にして説明するならば、まず、対応関係が１対１であるか否かを判定する。上記の例では、“３．１”に対して、「４．１．１．１」、「４．１．１．２」・・・等が対応付けられているので、対応関係は１対１ではない（１対複数である）ことになる。よって、この場合には、複数側（「４．１．１．１」等）は全てそのまま出力する。一方、単数側（“３．１”）は、所定のルールに従って例えば「３．１−ｍ」（ｍ＝１，２，３、・・・）を生成して、これらを上記複数側にそれぞれ対応付ける。これより、図６における「３．１−１，４．１．１．１」、「３．１−２，４．１．１．２」、「３．１−３，４．１．１．３」の部分が生成されると共に更に「３．１−４，４．１．１．４」が追加されることになる。

更に、“３．１”自身に対しては、「４．１．１．１」、「４．１．１．２」・・・等の１つ上の階層の章番号を対応付ける。章番号の規則性から考えて、当然、これら「４．１．１．１」等の１つ上の階層の章番号は「４．１．１」であるので、“３．１”に対しては「４．１．１」を対応付ける。これより、図６における「３．１，４．１．１」の部分が生成されることになる。

その後は、「要求仕様書」と「設計書」の両方で更に１つ上の階層の章番号を上記章番号の規則性に従って生成して、相互に対応付ける処理を行っていく。“３．１”の１つ上は‘３’であり、「４．１．１」の１つ上は「４．１」となるので、これより図６における「３，４．１」の部分が生成されることになる。これを例えば最上位階層の対応付けを行うまで繰り返す。

他も略同様にして生成できるので、上記関連一覧表から各リンク情報を生成できる。
尚、上記文書入力部７による処理は、上述した一例に限らない。例えば、取り込み対象の文書が、上記「アウトラインレベル」のような階層情報や、“見出し”や“本文”等の種別が付与されていない文書であった場合、例えば下記のようにして文書と取り込むようにしてもよい。

すなわち、例えば、取り込み対象の文書を順次スキャンし、タイトル部として識別できるデータの場合には、タイトル部３１として取り込み、それ以外の場合には、本文部３２として取り込む。例えば、先頭部分が数字である場合にはタイトル部であると判定すればよい（但し、この場合、例えばユーザに対する本文部３２の記述ルールとして「最初の文字は数字以外とする」等のルールを、予め設けておくことが望ましい）。そして、任意のデータをタイトル部３１として取り込む場合には、その先頭部分の数字（3.1,3.1.1,3.1.1.1のような数字；章番号）に応じて、階層を判定し、判定した階層のデータとして当該データを取り込む。階層の判定方法は、例えば章番号における‘．’の数に応じて、例えば「階層＝‘．’の数＋１」等とすればよい。この場合、上記3.1は階層２,3.1.1は階層３,3.1.1.1は階層４と判定されることになり、また‘３’の場合には‘．’が１つもないので階層１と判定されることになる。

尚、章番号は、所定の規則性（１，２，３・・・というように１から順番の番号となる）があるので、例えば階層２を例にすると、3.1、3.2、3.3の後が3.5等となることはあり得ないことになる。これより、上記データをタイトル部３１として取り込む際に、上記規則性に従ったチェックを行い、この規則性に違反するような章番号（上記３．３の後の３．５等）が現れたときは、エラーを出力し、処理を中止するようにしてもよい。

図１１は、本例の要件管理支援装置１のディスプレイ装置１２に表示される画面の例である。
図示のように、画面５０の上部には、主要な機能を実行するための命令ボタン群５１が配置されている（「ひな形生成」、「文書出力」、「文書取込」、「一覧表生成」など）。また、これら命令ボタン群５１の下の領域５２は、各文書のデータを切替え表示できるように、タブにより画面が切り替えられるようになっている。図では「要求仕様書」を表示させている状態を示している。尚、当然、単に表示させるだけでなく、ユーザが任意のデータを入力して文書を編集することもできる。

更に図示のようにタブのなかには仕様書等の文書名だけでなく「一覧表」も示されており、これを選択すると上記図９などに示す関連一覧表が表示される。尚、文書の数は階層の数に応じて変更できる。

図１１に示す画面上でのユーザ操作例は、例えば下記の通りである。
ユーザは、例えば最初に要求仕様書を記述する。これは、元になる文書がないので、直接図１１の画面上で記入するか、もしくは、章構成を記述した外部ファイルとして作成し、「文書取込」ボタンを押して取り込む。

上記のようにして要求仕様書を作成したら、次に、「ひな形生成」ボタンを押して、ひな形文書を自動生成させる。これは、「ひな形生成」ボタンを押すことで例えば図１２に示すようなポップアップ画面が表示される。ユーザは、図１２の画面上で、生成元文書、生成先文書や基点を任意に指定したうえで、「生成」ボタンを押すことで、生成先文書のひな形が自動的に生成されることになる。本例では、作成済みの文書は要求仕様書のみであるので、生成元文書は要求仕様書とする以外にないことになる。図示の例では、要求仕様書に基づいて設計書のひな形が自動的に生成されることになる。

そして、設計書のひな形が自動生成された後、ユーザが上記図１１の画面５０において「設計書」タブを指定することで、上記領域５２には設計書のひな形データが表示されることになる。ユーザは、このひな形に基づいて設計書を作成・完成させることになる。すなわち、例えば、ひな形において、タイトル部３１に関しては、章番号が付与されており、タイトルの記述も行われている（生成元文書のコピー）ので、そのままで良ければそのままとし、そのままでは適当ではないと思うならば適宜修正を加えることになる。また、本文部３２に関しては、上記の通り生成元文書のコピーが行われるが、これは特に必要なものではなく、基本的には必ずユーザによる記述が行われることになる。尚、本文部３２の記述を行うときには、適宜、章の追加、削除を行いながら記述するものであってもよい。

また、編集の際には、章の追加・削除、文章の入力モードの切り替え（本文入力／タイトル入力）、タイトルの章の段を１つ上げる、１つ下げる、等といった命令群が、記述を行うためには必要であるが、これらは例えばキーボードからコマンド入力を行うことにより実現させればよい。あるいは、図１１には示していないが、画面５０上にこれらの命令に対応するボタンを配置しても良い。また、図１１に示す画面５０上では、３章のみ表示しているが、取り込み時には、３章以外の章も同時に取り込み、編集を行うことも可能である。

図１１の画面上では編集操作が煩雑な場合や、プリントアウトしたい場合には、文書を外部出力してから行う。外部で編集してから取り込みを行う場合には、一覧表を作成し、これも外部出力する。外部で章を追加・削除した場合には、一覧表も同様に編集することにより、再度取り込みを行う場合にも矛盾なく取り込むことが可能となる。

最後に、上記図９等に示した関連一覧表の生成処理について、図１３のフローチャート図を参照して説明する。
尚、関連一覧表の生成処理の一例は、既に説明してあり、ここでは他の例について説明する。

図１３に示す処理は、全ての文書を対象にして（図９に示す例では６つの文書について）任意の２つの文書間の関連を抽出して記憶する処理となる（ステップＳ５００ａ−５００ｂ間でループする処理）。これは、例えば、図６に示すような関連情報を参照して行うことになる。よって、この例でも図６に示すような関連情報（リンク情報）が存在する２つの文書が、処理対象となる。

例えば、一例としては、「要求仕様書」と「設計書」とが対応付けられ（図６に示す通り）、「要求仕様書」と「型式試験仕様書」とが対応付けられ、「設計書」と「詳細設計書」とが対応付けられ、「設計書」と「機能試験仕様書」とが対応付けられ、「詳細設計書」と「単体試験仕様書」とが対応付けられるが、これらの例に限らない。

まず、上記ステップＳ１０１と同様にユーザが任意の基点の指定を行う（ステップＳ５０１）。そして、入力された基点から順に、各項目（本例では章番号とするがこの例に限らない）を順次処理対象としてステップＳ５０３〜Ｓ５０５の処理（ステップＳ５０２ａ−ｓ５０２ｂ間のループ処理）を行うことになる。

まず、処理対象項目が“本文”であるか否かを判定する（ステップＳ５０３）。これは例えば、章番号が存在しない項目は“本文”であると判定する。あるいは図６に示すような関連情報を参照する場合、末尾が“−番号”となっている場合には、“本文”であると判定する。

もし、処理対象項目が“本文”ではない場合には（ステップＳ５０３，ＮＯ）、この処理対象項目（その章番号等）を例えばメモリの所定領域に上書き記憶する（ステップＳ５０４）。そして、ステップＳ５０２ｂにおいて全項目について処理済みか否かを判定して、未だであればステップＳ５０２ａに戻り、次の項目を処理対象とする。

一方、処理対象項目が“本文”である場合には（ステップＳ５０３，ＹＥＳ）、上記メモリの所定領域に記憶してある項目（章番号等）を読み出して、これを例えば上記図９等に示した関連一覧表の該当箇所に登録する。更に、この読み出した項目に対応する項目を、この該当箇所に対応付けて登録する（ステップＳ５０５）。そして、上記ステップＳ５０２ｂへ移行する。

ここで、例えば一例として「要求仕様書」と「設計書」を例にし（「要求仕様書」と対応付け元、「設計書」を対応付け先とする）、「要求仕様書」の‘３’（３章）が基点に指定されたものとする。この例では、最初の処理対象項目は‘３’であるので、ステップＳ５０３はＮＯとなり‘３’が上記所定領域に記憶される。次の処理対象項目は‘３．１’であるので、今度もステップＳ５０３はＮＯとなり‘３．１’が上記所定領域に記憶される。

次の処理対象項目は‘３．１−１’であるので、今度はステップＳ５０３はＹＥＳとなり、ステップＳ５０５の処理が実行される。これは本例では上記所定領域に記憶されている‘３．１’が、関連一覧表の該当箇所（本例では「要求仕様書」のフィールド）に格納されると共に、現在の処理対象項目である‘３．１−１’に対応する「設計書」の項目は、図６の例から‘４．１．１．１’であることが分かるので、これを上記該当箇所に対応付けて（本例では「設計書」のフィールド）に格納される。これより、図９に示すように、「要求仕様書」の‘３．１’に「設計書」の‘４．１．１．１’が対応付けられて登録される。

更に、次の処理対象項目は‘３．１−２’であるので、今度もステップＳ５０３はＹＥＳとなり、ステップＳ５０５の処理が実行されるが、上記所定領域の記憶内容に変化はないので（‘３．１’が記憶されたままである）、関連一覧表には図９に示すように、「要求仕様書」の‘３．１’に「設計書」の‘４．１．１．２’が対応付けられて登録されることになる。

同様に、次の処理対象項目は‘３．１−３’であるので、今度もステップＳ５０３はＹＥＳとなり、ステップＳ５０５の処理が実行されるが、上記所定領域の記憶内容に変化はないので（‘３．１’が記憶されたままである）、関連一覧表には図９に示すように、「要求仕様書」の‘３．１’に「設計書」の‘４．１．１．３’が対応付けられて登録されることになる。

次の処理対象項目は‘３．２’であるので、今度はステップＳ５０３がＮＯとなり、上記所定領域には‘３．２’が上書きされる。
そして、次の処理対象項目は‘３．２−１’であるので、ステップＳ５０３はＹＥＳとなり、ステップＳ５０５の処理が実行される。このとき、上記所定領域には‘３．２’が記憶されているので、これより、関連一覧表には図９に示すように、「要求仕様書」の‘３．２’に「設計書」の‘４．１．２．１’が対応付けられて登録されることになる。

更に、次の処理対象項目は‘３．２−２’であるので、今度もステップＳ５０３はＹＥＳとなり、ステップＳ５０５の処理が実行されるが、上記所定領域の記憶内容に変化はないので（‘３．２’が記憶されたままである）、関連一覧表には図９に示すように、「要求仕様書」の‘３．２’に「設計書」の‘４．１．２．２’が対応付けられて登録されることになる。

尚、後に、関連一覧表において同一項目は１つにまとめるようにしてもよい。これより、図９に示すように、上記３つの‘３．１’は１つにまとめられて、この‘３．１’に対して「設計書」の‘４．１．１．１’、‘４．１．１．２’、‘４．１．１．３’が対応付けられて登録された状態となる。同様に、上記２つの‘３．２’は１つにまとめられて、この‘３．２’に対して「設計書」の‘４．１．２．１’、‘４．１．２．２’が対応付けられて登録された状態となる。

尚、ユーザが処理開始前に処理対象の２つの文書の関係に応じたタイプ指定を行うことで、処理アルゴリズムが切り換わるようにしてもよい。例えば一例としては、処理対象の２つの文書の関係として、図５に示すようなタイプ（タイプＡとする）と、図８に示すようなタイプ（タイプＢとする）とがあるとした場合、ユーザがタイプＡを指定すると上述した図１３の処理が実行される。

一方、ユーザがタイプＢを指定した場合にも、基本的には上述した図１３の処理が実行されるが、一部、アルゴリズムが異なる部分がある。
すなわち、タイプＢの場合、上記ステップＳ５０５において、もし対応付け先（本例では「設計書」）に登録すべき項目（本例では章番号）が無かった場合には、例えば直前の項目を出力するようにしてもよい。例えば図８に示す「要求仕様書」と「型式試験仕様書」の例の場合、「要求仕様書」の‘３．１−１’（すなわち本文）に対して「型式試験仕様書」側も本文となっているので、上記処理では関連一覧表において「要求仕様書」に関しては‘３．１’が登録されるが、「型式試験仕様書」にはこれに対応付けて登録すべき項目（本例では章番号）が無いことになる。この為、この場合には、直前の項目である‘２．１’を登録する。これより、図９に示すように、「要求仕様書」の‘３．１’に対して、「型式試験仕様書」は‘２．１’が登録されることになる。

以上説明したように、本例の要件管理支援装置１では、上位側の文書の章構成で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、これを下位側文書のひな形として提供する。その際、関連情報が生成されて登録するようにしてもよい。文書作成者は、このひな形に詳細な設計情報を入力することにより、文書として完成させる。

また、変更等があったときに対応関係を維持するために、上記関連情報を一覧表の形で自動的に生成して、記憶／出力するようにしてもよい。
また、上記の文書や関連一覧表を、要件管理支援装置１の外部で、ワードプロセッサやエディタ、スプレッドシートなどで編集できるように、外部出力することもできる。その際、出力した文書には、文書構成の情報を付帯させ、文書の構成要素同士の関連は、関連一覧表で識別できるようにする。

また、外部のワードプロセッサやエディタ、スプレッドシートなどで編集した、これらの文書や関連一覧表を要件管理支援装置に取り込み、データを維持するために、関連一覧表の情報を元に、文書の間の関連情報を自動的に生成するようにしてもよい。

以上説明したように、本例の要件管理支援装置１によれば、上位側の文書の章構成で規定される文書構成から、下位側の文書の章構成で規定される文書構成を導出し、下位側文書のひな形として提供する。その際、上位側の文書の各項目と下位側の文書の各項目との関連情報（文書間の対応関係を示す情報；リンク情報）も、自動的に生成・付与される。文書作成者は、このひな形に詳細な設計情報を入力することにより、文書として完成させる。

また、文書内容に変更等があった場合でも文書間の対応関係を維持できるようにするために、上記関連情報を一覧表の形で、自動的に生成・出力する。
また、これらの文書や一覧表を、要件管理支援装置１の外部で、ワードプロセッサやエディタ、スプレッドシートなどで編集できるように、外部出力する。その際、出力した文書には、文書構成の情報（階層等）を付帯させる。更に、上記一覧表も一緒に出力して、文書の構成要素同士の関連は、一覧表で識別できるようにする。

また、上記のように要件管理支援装置１の外部へ出力した文書を、ユーザがワードプロセッサやエディタ、スプレッドシートなどで任意に自由に編集した場合、編集後の文書に応じて一覧表も編集した後、これらの編集後の文書や一覧表を、再び要件管理支援装置１に取り込むようにしてもよい。その際、一覧表の情報を元に、文書の間の関連情報（リンク情報）を自動的に生成する。

本例の要件管理支援装置１によれば、章番号が付与され相互に関連し得る複数の文書の生成、文書間の各項目間のリンク付けを、より効率的に行えると共に項目漏れの防止もできる。上記複数の文書を作成する際に、例えば１つの文書を作成すれば、他の文書に関しては、当該作成済みの文書に基づいてひな形を作成すると共にリンク付けも自動的に行われる。よって、他の文書に関しては、特に文書の新規作成時に、効率よく文書作成を行えると共に、他の文書との関連情報（リンク情報）により管理された文書が自動的に作成されることになる。

特に章番号が付与される複数の文書であって相互に関連する複数の文書に関して、上位側の文書に基づいて下位側の文書の章番号やタイトル名等を自動的に付与することができ、また関連する章同士をリンク付けでき、以って変更があった場合にも効率的に維持管理することができる。更に、項目漏れ、リンク付け漏れ等のミスも防止できる。

上記複数の文書がソフトウェアの設計に係る各種文書である場合には、正しいソフトウェアを効率良く製作することができるようになる。

１ 要件管理支援装置
２ 上位側文書解析部
３ 下位側文書生成部
４ 関連情報生成部
５ 文書格納部
５ａ 文書
５ｂ 関連情報
６ 文書出力部
７ 文書入力部
８ 関連情報解析部
１０ 端末（パソコン）
１１ 主記憶装置
１２ ディスプレイ装置
１３ 補助記憶装置
１４ 入力装置
１５ バス
１６ 演算装置
２１ 上位側文書
２２ 下位側文書
２３ 関連情報
３１ タイトル部
３２ 本文部
４１ 文書識別部
４２ 章構成対応部
５０ 画面
５１ 命令ボタン群
５２ 領域

Claims (7)

1. 各々が章番号を有する文書であって相互に関連し得る複数の文書の作成を支援する装置であって、
   任意の１以上の前記文書を任意に作成させる文書作成支援手段と、
   前記作成された文書の何れか１つを上位側文書とし、該上位側文書に基づいて、該上位側文書に関連する他の文書としての下位側文書のひな形を生成するひな形生成手段と、
   前記上位側文書の各項目と下位側文書のひな形の各項目との関連を示す関連情報を生成する関連情報生成手段とを有し、
   前記文書作成支援手段は、前記ひな形に基づく前記下位側文書の作成を支援することを特徴とする要件管理支援装置。
2. 前記ひな形生成手段は、前記上位側文書の章構成で規定される文書構成から前記下位側文書の章構成で規定される文書構成を導出することで、該下位側文書のひな形を生成することを特徴とする請求項１記載の要件管理支援装置。
3. 前記ひな形生成手段は、任意に設定される基点となる章番号と前記上位側文書の章構成で規定される文書構成に基づいて、前記下位側文書の章番号、タイトル名を導出することで、該下位側文書のひな形を生成することを特徴とする請求項２記載の要件管理支援装置。
4. 前記上位側文書−下位側文書間の関連情報に基づいて、前記各文書間の各項目間の関連を示す関連一覧表を生成する関連一覧表生成手段を更に有することを特徴とする請求項１記載の要件管理支援装置。
5. 前記文書作成支援手段で生成された文書を、その文書構成を保ちながら外部出力する文書出力手段を更に有することを特徴とする請求項１に記載の要件管理支援装置。
6. 外部の任意の文書形式で生成された任意の文書を、前記章構成で規定される文書構成の文書に変換して入力すると共に、該入力文書の各項目と前記生成されている他の文書の各項目との関連を示す関連情報を生成する文書入力手段を更に有することを特徴とする請求項１に記載の要件管理支援装置。
7. 前記文書は設計文書であることを特徴とする請求項１〜６の何れかに記載の要件管理支援装置。
   
   

Images