JPWO2017199443A1 - テンプレート生成装置、テンプレート生成プログラム及びテンプレート生成方法 - Google Patents

Abstract

第１抽出部（９１０）は、要求仕様書（５１）、外部仕様書（５２）、内部仕様書（５３）を複数の領域に分割し、各領域からキーワードを抽出する。第２抽出部（９２０）は複数の領域からなるソースコードからオブジェクトごとにファンクションリストを生成し、ファンクションリストからキーワードを抽出する。生成部（９３０）は、抽出されたキーワードを用いて、ソースコード（５４）、内部仕様書（５３）、外部仕様書（５２）、要求仕様書（５１）の各領域の計４領域の対応付けを示す対応付け情報を製品ごとに生成する。決定部（９４０）は、複数の製品の中に、対応付け情報の示す４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定する。

Description

本発明は、ソフトウェア開発過程における、要求仕様書、外部設計書、内部設計書及びソースコードのそれぞれのテンプレートを生成するテンプレート生成装置に関する。

類似製品の仕様書作成を支援する市販ツールはなく、通常、類似製品の仕様書を作成する場合、既存の仕様書をコピーアンドペーストし、部分的に変更箇所を改訂することで、類似製品の仕様書が作成されることが一般的であった。

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

特許文献１については、Ｄｏｘｙｇｅｎ等の既存の解析ソフトウェアを用いて、ソースコードから設計書を自動生成する。しかし、ここでの設計書は内部設計書相当のものであり、要求仕様書や外部設計書までは自動生成できない。

また、特許文献２は、ソースコードを閲覧しているときに、参考となる設計書を表示するが、この表示に止まり、設計書やソースコードのテンプレートを自動生成する技術ではない。

この発明は、既存の複数製品の要求仕様書、外部設計書、外部設計書、ソースコードから、新たに開発される製品の要求仕様書、外部設計書、外部設計書、ソースコードのそれぞれのテンプレートを生成する装置の提供を目的とする。

この発明のテンプレート生成装置は、
いずれも電子データである一つの製品の要求仕様書、外部仕様書、内部仕様書を複数の領域に分割し、各領域からキーワードを抽出する第１抽出部と、
複数の記述領域である複数の領域からなる前記製品の電子データであるソースコードからオブジェクトごとにファンクションリストを生成し、前記ファンクションリストからキーワードを抽出する第２抽出部と、
抽出されたキーワードを用いて、前記ソースコードの領域と、前記内部仕様書の領域と、前記外部仕様書の領域と、前記要求仕様書の領域との４領域の対応付けを示す対応付け情報を製品ごとに生成する生成部と、
複数の製品の中に、前記対応付け情報で対応付けが示される４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定し、存在する場合に、いずれかの前記類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用するかどうか決定する決定部と
を備える。

本発明のテンプレート生成装置によれば、サンプル文書のようにベースとなる書類が自動生成される。よって、開発プロジェクトの参加設計者が開発製品の設計技術に熟達していない場合であっても、ベースとなる共通的なサンプル文書を用意することができる。よって、効率的に仕様書作成ができる。

実施の形態１の図で、テンプレート生成装置の構成図。 実施の形態１の図で、テンプレート生成装置の処理工程を示す図。 実施の形態１の図で、テンプレート生成装置の前段処理１Ａの構成図。 実施の形態１の図で、テンプレート生成装置の前段処理１Ａの構成図。 実施の形態１の図で、テンプレート生成装置の後段処理１Ｂの構成図。 実施の形態１の図で、テンプレート生成装置の動作概要を示す図。 実施の形態１の図で、類似領域グループと製品の個数との関係を示す図。 実施の形態１の図で、前段処理１Ａの動作を示すフローチャート。 実施の形態１の図で、後段処理１Ｂの動作を示すフローチャート。 実施の形態１の図で、外部仕様書に相当するＯｐｅｎＥＬ ２．０の仕様書の目次構成の例を示す図。 実施の形態１の図で、前段処理１Ａの処理フローを示す図。 実施の形態１の図で、前段処理１Ａのキーワード抽出を説明するフローチャート。 実施の形態１の図で、ソースコード解析部２１によってソースコード５４から抽出されるＡＰＩ仕様の情報を示す図。 実施の形態１の図で、外部仕様書５２の各文章領域のキーワードを示す図。 実施の形態１の図で、要求仕様書５１の各文章領域のキーワードを示す図。 実施の形態１の図で、内部仕様書５３の各文章領域のキーワードを示す図。 実施の形態１の図で、ソースコード５４に含まれるＡＰＩ名称を示す図。 実施の形態１の図で、内部仕様書５３に含まれるＡＰＩ名称を示す図。 実施の形態１の図で、ソースコード５４の領域と内部仕様書５３の領域との対応付けを示す図。 実施の形態１の図で、内部仕様書５３の領域と外部仕様書５２の領域との対応付けを示す図。 実施の形態１の図で、外部仕様書５２の領域と要求仕様書５１の領域との対応付けを示す図。 実施の形態１の図で、後段処理１Ｂの処理フローを示す図。 実施の形態１の図で、対応付け情報を示す図。 実施の形態１の図で、要求仕様書５１のテンプレートの例を示す図。 実施の形態１の図で、外部仕様書５２のテンプレートの例を示す図。 実施の形態１の図で、内部仕様書５３のテンプレートの例を示す図。 実施の形態１の図で、ソースコード５４のテンプレートの例を示す図。 実施の形態１の図で、各文章領域の主要キーワードとして抽出できたものを表形式で記載したサンプルを示す図。 実施の形態１の図で、後段処理にて共通的なオブジェクトと関数を抽出する処理を示した図。 実施の形態１の図で、テンプレート生成装置のハードウェア構成を示す図。 実施の形態２の図で、要求仕様書５１−２の目次を示す図。 実施の形態２の図で、図３１から続く要求仕様書５１−２の目次を示す図。 実施の形態２の図で、外部仕様書５２の簡略な目次構成案を示す図。 実施の形態２の図で、要求仕様書５１−２から抽出された主要キーワードを示す図。 実施の形態２の図で、第１の対応抽出部３１ａによる処理結果を示す図。 実施の形態３の図で、外部仕様書５２に相当するＷｅｂ ＡＰＩの一覧を示す図。 実施の形態３の図で、Ｗｅｂ ＡＰＩのソースコードファイル一覧を示す図。 実施の形態３の図で、基本設計書の主要目次項目を示す図。

実施の形態１．
図１から図３０を参照して、実施の形態１のテンプレート生成装置１を説明する。実施の形態１のテンプレート生成装置１の特徴は、ソースコードを解析して、各オブジェクトやファンクションに対応する設計書の文章領域を抽出する点にある。テンプレート生成装置１は、内部仕様書から外部仕様書、要求仕様書へと設計の上流へ、対応する文章領域への展開を図る。
（１）内部仕様書は、内部設計書、詳細設計書などと呼ばれる場合もあるが、本実施の形態では、内部仕様書と記す。
（２）外部仕様書は、外部設計書、概略設計書などと呼ばれる場合もあるが、本実施の形態では、外部仕様書と記す。

なおテンプレート生成装置１の利用件として、１つ以上の製品で、要求仕様書、外部仕様書、内部仕様書、ソースコードが、章節等の目次構成を備えていること想定する。要求仕様書、外部仕様書、内部仕様書、ソースコードは、製品設計データである。

＜＊＊＊構成の説明＊＊＊＞

図１〜図５を用いて、実施の形態１のテンプレート生成装置１の構成を説明する。
図１は、テンプレート生成装置１の構成を示す。テンプレート生成装置１は、コンピュータである。テンプレート生成装置１は、プロセッサ９０１、記憶装置９０２、入力インタフェース９０３、出力インタフェース９０４等のハードウェアを備える。入力インタフェース９０３は入力ＩＦ９０３と記し、出力インタフェース９０４は出力ＩＦ９０４と記す。テンプレート生成装置１は、構成機能として、第１抽出部９１０、第２抽出部９２０、生成部９３０、決定部９４０を有する。

以下の説明では、テンプレート生成装置１における、第１抽出部９１０と、第２抽出部９２０と、生成部９３０と、決定部９４０との機能を、テンプレート生成装置１の「部」の機能という。テンプレート生成装置１の「部」の機能は、ソフトウェアで実現される。第１抽出部９１０、第２抽出部９２０等は、後述する図３〜図５に示すように、さらに、複数の機能部からなる。第１抽出部９１０等を構成するさらに具体的な機能部は後述する。

記憶装置９０２は、補助記憶装置９０２ａ及びメモリ９０２ｂを含む。補助記憶装置９０２ａは、具体的には、ＲＯＭ（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、フラッシュメモリ、又は、ＨＤＤ（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）である。メモリ９０２ｂは、具体的には、ＲＡＭ（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）である。

入力ＩＦ９０３は、信号が入力されるポートである。また、入力ＩＦ９０３は、マウス、キーボード、タッチパネルといった入力装置と接続されるポートであってもよい。入力ＩＦ９０３は、具体的には、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ・Ｓｅｒｉａｌ・Ｂｕｓ）端子である。なお、入力ＩＦ９０３は、ＬＡＮ（Ｌｏｃａｌ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）と接続されるポートであってもよい。

出力ＩＦ９０４は、信号を出力するポートである。出力ＩＦ９０４は、ＵＳＢ端子でもよい。

補助記憶装置９０２ａには、プロセッサ９０１として示す「部」の機能を実現するプログラムが記憶されている。このプログラムは、メモリ９０２ｂにロードされ、プロセッサ９０１に読み込まれ、プロセッサ９０１によって実行される。補助記憶装置９０２ａには、ＯＳ（Ｏｐｅｒａｔｉｎｇ・Ｓｙｓｔｅｍ）も記憶されている。ＯＳの少なくとも一部がメモリ９０２ｂにロードされ、プロセッサ９０１はＯＳを実行しながら、プロセッサ９０１として示す「部」の機能を実現するプログラムを実行する。

図２は、テンプレート生成装置１の処理を示す機能ブロック図である。テンプレート生成装置１は、前段処理１Ａと後段処理１Ｂとを実行して、テンプレート群７０を生成する。前段処理１Ａは、第１抽出部９１０と第２抽出部９２０と生成部９３０とが実行する。後段処理１Ｂは、決定部９４０が実行する。後段処理１Ｂには前段処理１Ａの実行結果が入力され、後段処理１Ｂはテンプレート群７０を出力する。テンプレート群７０とは、要求仕様書のテンプレート、外部仕様書のテンプレート、内部仕様書のテンプレート、ソースコードのテンプレートである。

（１）前段処理１Ａでは、テンプレート生成装置１には、まずＰ製品の要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が入力され、テンプレート生成装置１は、Ｐ製品の前段処理１Ａを実施する。
（２）次に、Ｑ製品の要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が入力され、テンプレート生成装置１は、Ｑ製品の前段処理１Ａを実施する。
（３）以下同様に、Ｒ製品、Ｓ製品等の要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が入力され、テンプレート生成装置１は、Ｑ製品、Ｓ製品等の前段処理１Ａを実施する。前段処理１Ａの具体的な内容は図３、図４で後述する。なお前段処理１Ａに入力されるのは２以上の製品の、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４を想定している。

後段処理１Ｂでは、前段処理１Ａによる実行結果である、製品Ｐの対応付け情報６１、製品Ｑの対応付け情報６２、製品Ｒの対応付け情報６３が入力される。「対応付け情報」は後述する。

図３は、テンプレート生成装置１の前段処理１Ａを実行する、テンプレート生成装置１の機能部を示す。
（１）第１抽出部９１０は、分割部１１、第１のキーワード抽出部１２を備える。
（２）第２抽出部９２０は、ソースコード解析部２１、ファンクションリスト生成部２２、第２のキーワード抽出部２３を備える。
（３）生成部９３０は、第１の対応抽出部３１ａ、第２の対応抽出部３１ｂ、第３の対応抽出部３１ｃ、対応付け情報生成部３２を備える。

図４は、生成部９３０が、さらに、トレーサビリティ情報取得部３３ａ，３３ｂ，３３ｃ、相互関係判定部３４を備える。図４は、図３に対して、生成部９３０にトレーサビリティ情報取得部３３ａ，３３ｂ，３３ｃ、相互関係判定部３４が追加された点が異なる。

図５は、テンプレート生成装置１の後段処理１Ｂを実行する、テンプレート生成装置１の「部」の機能を示す。決定部９４０は、対応判定部４１、カウント部４１ａ、文章解析部４１ｂ、重要度判定部４２、テンプレート出力部４３、空欄作成部４４を備える。

＊＊＊動作の説明＊＊＊
図１、図６を参照して、テンプレート生成装置１の動作の概要を説明する。
図６は、テンプレート生成装置１の動作の概要を説明するための図である。

テンプレート生成装置１には、入力インタフェース９０３から、Ｐ製品の要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が入力される。まず、テンプレート生成装置１は、Ｐ製品の前段処理１Ａを実施する。入力インタフェース９０３から入力される要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４は、いずれも電子データである。第１抽出部９１０は、一つの製品の要求仕様書５１、外部仕様書５２、内部仕様書５３を複数の領域に分割し、各領域からキーワードを抽出する。図６は、製品Ｐ，Ｑ，Ｒの要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４を示している。上段が製品Ｐ、中段が製品Ｑ、下段が製品Ｒである。以下、製品Ｐについて図６を説明するが他の製品についても同じである。

要求仕様書５１、外部仕様書５２、内部仕様書５３は４段になっている。これは第１抽出部９１０が要求仕様書５１等を複数の領域（４つの領域）に分割したことを示す。また４段の各矢印は、抽出されるキーワードを示す。他の製品も同じである。第１抽出部９１０は、要求仕様書５１について、１段目（最上段）の領域からモータを、２段目の領域からジャイロセンサを、３段目の領域からトルクセンサを、キーワードとして抽出したことを示す。
第２抽出部９２０は、複数の記述領域である複数の領域からなるソースコード５４からオブジェクトごとにファンクションリストを生成し、ファンクションリストからキーワードを抽出する。図６ではファンクションリスト（後述する）は示していない。図６は、ファンクションリストからモータ、ジャイロセンサ、トルクセンサがキーワードとして抽出され、これらのキーワードは、ソースコード５４における１段目の領域、２段目の領域、３段目の領域に存在することを示している。

生成部９３０は、抽出されたキーワードを用いて、ソースコード５４の領域と、内部仕様書５３の領域と、外部仕様書５２の領域と、要求仕様書５１の領域との４領域の対応付けを示す「対応付け情報」を製品ごとに生成する。図６において、生成部９３０は、抽出されたキーワードのモータを用いて、ソースコード５４の１段目の領域と、内部仕様書５３の１段目の領域と、外部仕様書５２の１段目の領域と、要求仕様書５１の１段目の領域との４領域の対応付けを示す「対応付け情報６１−１」を生成する。つまり、モータというキーワードが同じであるため、生成部９３０は、ソースコード５４、内部仕様書５３、外部仕様書５２、要求仕様書５１の各１段目を、「対応付け情報６１−１」として対応付ける。
同じように、生成部９３０は、抽出されたキーワードのジャイロセンサを用いて、ソースコード５４の２段目の領域と、内部仕様書５３の２段目の領域と、外部仕様書５２の領域の２段目と、要求仕様書５１の２段目の領域との４領域の対応付けを示す「対応付け情報６１−２」を生成する。同じように、生成部９３０は、抽出されたキーワードのトルクセンサを用いて、ソースコード５４の３段目の領域と、内部仕様書５３の３段目の領域と、外部仕様書５２の３段目の領域と、要求仕様書５１の３段目の領域との４領域の対応付けを示す「対応付け情報６１−３」を生成する。
なお、製品Ｑからはトルクセンサがキーワードとして抽出されず、製品Ｒからはジャイロセンサがキーワードとして抽出されなかったとする。

第１抽出部９１０，第２抽出部９２０、生成部９３０は前段処理１Ａを実行するが、前段処理１Ａは製品ごとである。これに対して決定部９４０は後段処理１Ｂを実行するが、後段処理１Ｂは複数の製品を対象とする。

決定部９４０は、複数の製品の中に、対応付け情報で対応付けが示される４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定する。決定部９４０は、存在する場合に、いずれかの類似領域グループの４領域を、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４の各テンプレートに採用するかどうか決定する。

具体的には以下のようである。決定部９４０は、Ｐ，Ｑ，Ｒの製品の中に、「対応付け情報６１−１」等で対応付けが示される４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定する。具体例で説明する。「対応付け情報６１−１」は、ソースコード５４、内部仕様書５３、外部仕様書５２、要求仕様書５１の各１段目の領域を対応付ける。「領域グループ」とは、「対応付け情報６１−１」で対応が示される、ソースコード５４の一つの領域、内部仕様書５３の一つの領域、外部仕様書５２の一つの領域、要求仕様書５１の一つの領域の計４領域からなる領域のグループである。図６には、「対応付け情報６１−１」で示される領域グループとして、領域グループ６１Ｇ−１を示した。製品Ｑの場合、「対応付け情報６２−１」で示される領域グループは領域グループ６２Ｇ−１である。
決定部９４０は製品を異にする領域グループである領域グループ６１Ｇ−１と領域グループ６２Ｇ−１とが類似するか判定する。類似の判定方式は後述する。決定部９４０は、類似領域グループが存在する場合に、いずれかの類似領域グループの４領域を、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４の各テンプレートに採用するかどうか決定する。この決定方式は後述する。

対応付け情報を生成する場合、生成部９３０は、抽出されたキーワードを用いて、ソースコード５４の領域と内部仕様書５３の領域とを対応付ける。
次に、抽出されたキーワードを用いて、生成部９３０は、ソースコード５４の領域に対応付けられた内部仕様書５３の領域と、外部仕様書５２の領域とを対応付ける。
次に、抽出されたキーワードを用いて、生成部９３０は、内部仕様書５３の領域を介してソースコード５４の領域に対応付けられた外部仕様書５２の領域と、要求仕様書５１の領域とを対応付ける。

以上により、生成部９３０は、ソースコード５４の領域と、内部仕様書５３の領域と、外部仕様書５２の領域と、要求仕様書５１の領域との４領域を対応付ける。つまり、図６の場合、まず、生成部９３０は、抽出されたキーワードである「モータ」を用いて、ソースコード５４の１段目の領域と内部仕様書５３の１段目の領域とを対応付ける。
次に、「モータ」を用いて、生成部９３０は、ソースコード５４の１段目の領域に対応付けられた内部仕様書５３の１段目の領域と、外部仕様書５２の領域とを対応付ける。
次に、「モータ」を用いて、生成部９３０は、内部仕様書５３の１段目の領域を介してソースコード５４の１段目の領域に対応付けられた外部仕様書５２の１段目の領域と、要求仕様書５１の領域とを対応付ける。
以上により、生成部９３０は、ソースコード５４、内部仕様書５３、外部仕様書５２、要求仕様書５１の各１段目の領域を対応付けで対応付け情報６１−１を生成する。

決定部９４０は、各製品の領域グループに含まれるキーワードであって、第１抽出部９１０と第２抽出部９２０とが抽出したキーワードである「抽出キーワード」を用いて、類似領域グループが存在するか判定する。つまり、図６の場合、領域グループ６１Ｇ−１と、領域グループ６２Ｇ−１とが類似するか、決定部９４０は、第１抽出部９１０が抽出した「モータ」によって判定する。この場合、決定部９４０は、同一の「抽出キーワード」の出現頻度を用いて、類似領域グループが存在するか判定する。
具体的には以下のようである。図６では領域グループ６１Ｇ−１、６２Ｇ−１において、要求仕様書５１等の各１段目からは「モータ」がキーワードとして抽出されるが、各１段目から「モータ、ジャイロセンサ」が抽出されたとする。

この場合、領域グループ６１Ｇ−１、６２Ｇ−１の各１段目からは、例えば１：９の比率のように、「ジャイロセンサ」に比べて多くの「モータ」が抽出される場合、決定部９４０は、領域グループ６１Ｇ−１、６２Ｇ−１は、特徴点を「モータ」として互いに類似する類似領域グループと判定する。一方、領域グループ６１Ｇ−１の各１段目からは１：９の比率で多くの「モータ」が抽出され、領域グループ６２Ｇ−１の各１段目からは１：９の比率で多くの「ジャイロセンサ」が抽出された場合、決定部９４０は、領域グループ６１Ｇ−１、６２Ｇ−１は、類似領域グループではないと判定する。

上記では類似領域グループが存在するかどうか、「抽出キーワード」で判定したが以下のように要約を用いてもよい。決定部９４０は、領域グループにおける内部仕様書５３の領域と、外部仕様書５２の領域と、要求仕様書５１の領域とのうちの少なくともいずれかの領域の要約を生成し、異なる製品の領域グループどうしの要約を比較することによって、類似領域グループが存在するか判定してもよい。

決定部９４０は、特徴点を同じくして互いに類似する類似領域グループが存在する製品の個数に基づいて、いずれかの類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用することを決定する。
図７は、図６において、類似領域グループが存在する製品の個数を説明する図である。図６において、キーワードの「モータ」が同じである領域グループ６１Ｇ−１、領域グループ６２Ｇ−１、領域グループ６３Ｇ−１が、「モータ」を特徴点として互いに類似する類似領域グループであるとする。また、キーワードの「ジャイロセンサ」が同じである領域グループ６１Ｇ−２、領域グループ６２Ｇ−２が、「ジャイロセンサ」を特徴点として互いに類似する類似領域グループであるとする。また、キーワードの「トルクセンサ」が同じである領域グループ６１Ｇ−３、領域グループ６３Ｇ−２が、「トルクセンサ」を特徴点として互いに類似する類似領域グループであるとする。

この場合、特徴点を同じくして類似する類似領域グループが存在する製品の個数は、図７の丸印の個数である。決定部９４０は、特徴点を同じくして類似する類似領域グループが存在する製品の個数で、いずれかの類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用することを決定する。特徴点が「モータ」の製品の個数は３個、特徴点が「ジャイロセンサ」の製品の個数は２個、特徴点が「トルクロセンサ」の製品の個数は２個である。決定部９４０は、例えば、特徴点が「モータ」である類似領域グループを選択する。この場合、領域グループ６１Ｇ−１、６２Ｇ−１、６３Ｇ−１のそれぞれが類似領域グループである。この例では、決定部９４０は、どの領域グループをテンプレート作成用に決定してもよい。決定部９４０は、領域グループ６１Ｇ−１をテンプレート作成用に決定するとする。その場合、決定部９４０は、領域グループ６１Ｇ−１に含まれる、ソースコード５４、内部仕様書５３、外部仕様書５２、要求仕様書５１の各１段目の領域を、ソースコード、内部仕様書、外部仕様書、要求仕様書の各テンプレートに採用する。

図８は、前段処理１Ａの動作を示すフローチャートである。
図９は、後段処理１Ｂの動作を示すフローチャートである。
図８、図９を参照して、前段処理１Ａ、後段処理１Ｂの処理内容を、具体例に沿って、以下に説明する。前段処理１Ａは、図４に示す前段処理１Ａによって実行され、後段処理１Ｂは、図５に示す後処理１Ｂによって実行されるものとする。つまり前段処理１Ａは、分割部１１等によって実行され、後段処理１Ｂは対応判定部４１等によって実行される。

なお、以下の具体例では、一般公開されている情報を使用して説明する。

本実施の形態では、既存のソフトウェア資産の例として、一般社団法人組込みシステム技術協会により策定されたＯｐｅｎＥＬを取り上げる。ＯｐｅｎＥＬ（Ｏｐｅｎ Ｅｍｂｅｄｄｅｄ Ｌｉｂｒａｒｙ）とは、ロボット、制御システムなどのソフトウェアの実装仕様を標準化する組込みシステム向けのオープンなプラットフォームである（ｈｔｔｐ：／／ｊａｓａ．ｏｒ．ｊｐ／ｏｐｅｎｅｌ／Ｍａｉｎ＿Ｐａｇｅ／ｊａ）。具体的には、ＯｐｅｎＥＬは、センサ入力やモータへの出力等、機器制御のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を、ミドルウェアよりも低いレイヤで標準化したプラットフォームである。ＯｐｅｎＥＬは、デバイスドライバ等のソフトウェアの移植性、再利用性、生産性を向上するための仕組みである。ＯｐｅｎＥＬに関する情報は、一般社団法人組込みシステム技術協会のホームページよりダウンロードできる。

なお、ＯｐｅｎＥＬにおいて公開されている情報としては、現在、外部仕様書５２に相当する仕様書しかない。このため、要求仕様書５１、内部仕様書５３、ソースコード５４は、実施の形態１では仮定して説明する。

図４に示すように、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が、前段処理１Ａに入力されるデータである。前段処理１Ａに入力される要求仕様書５１、外部仕様書５２、内部仕様書５３は、電子データの文書である。前段処理１Ａに入力されるソースコード５４も電子データである。

要求仕様書５１、外部仕様書５２、内部仕様書５３は、一般的に、章、節、項などのように、目次構成を持つ。
図１０は、ＯｐｅｎＥＬ ２．０における仕様書の目次である。図１０は、外部仕様書５２に相当する、ＯｐｅｎＥＬ ２．０の仕様書である、ＯｐｅｎＥＬ ２．０に関する各仕様書は、図１０のような、目次構成を持つ。

＜＊＊＊前段処理１Ａの動作の説明＊＊＊＞
図８、図１１、図１２を参照して、前段処理１Ａの動作を説明する。
図８は、図４のブロック図に対応する形式の処理フローである。
図１１も前段処理１Ａの処理フローであり、図８に対応する処理には図８のステップ番号を付している。

図１２は、第１のキーワード抽出部１２及び第２のキーワード抽出部２３の処理フローである。つまり、図１２は、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が読み込まれた後に、分割部１１が、要求仕様書５１、外部仕様書５２、内部仕様書５３を文章領域に分割し、第２抽出部９２０が、ソースコード５４を関数領域に分割し、キーワードを抽出するフローチャートである。

入力ＩＦ９０３には、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４が入力される。要求仕様書５１等は、入力ＩＦ９０３から入力された場合、補助記憶装置９０２ｂに保存される。第１抽出部９１０、第２抽出部９２０、生成部９３０、決定部９４０によって生成されたデータは、補助記憶装置９０２ａに記憶される。第１抽出部９１０、第２抽出部９２０、生成部９３０、決定部９４０が処理を行う場合、第１抽出部９１０等はデータを補助記憶装置９０２ａからメモリ９０ｂにロードする。そして、第１抽出部９１０等は、メモリ９０２ｂからデータを読み出し、あるいは、メモリ９０２ｂにデータを書き込み、処理を進める。

（Ｓ１１：仕様書の分割）
ステップＳ１１において、図６で説明したように、分割部１１は、要求仕様書５１等の文章領域を章、節の構造に合わせて、文章データとして分割する。要求仕様書５１を例にとれば、分割部１１は、要求仕様書５１の各章、各節等の、番号で識別される文章領域を要求仕様書５１から切り出し、切り出した各文章領域を章、節番号と対応付ける。要するに前段処理１Ａでは、「７．１」のような章、節等の番号を指定すると、分割部１１が該当する文章領域の文章データを取り出す。この機能は、マイクロソフト社のワード等の一般的な構造化エディタのソフトウェアが備えている。

（Ｓ１２：キーワードの抽出）
次に、ステップＳ１２において、図６で説明したように、切り出された文章領域ごとに、第１のキーワード抽出部１２は、文書データから主要キーワードをランク付けして抽出し、主要キーワードを選び出す。この機能を備えるソフトウェアは、代表的なものとして要約作成ソフトウェアである。例としては、フリーウェアのＥＫＷｏｒｄｓ（ｈｔｔｐ：／／ｗｗｗ．ｄｊｓｏｆｔ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｅｋｗｏｒｄｓ．ｈｔｍｌ）がある。

以上のステップＳ１１、ステップＳ１２では要求仕様書５１を例に説明したが、外部仕様書５２、内部仕様書５３も、要求仕様書５１と同様に処理される。

ステップＳ１１、ステップＳ１２の処理により、要求仕様書５１、外部仕様書５２、内部仕様書５３については、それぞれの文章領域ごとのキーワードが抽出できる。次にソースコード５４の取り扱いについて説明する。

（Ｓ２１：ソースコードの解析）
ステップＳ２１において、ソースコード解析部２１は、ソースコード５４を解析し、ソースコード５４のそれぞれの記述領域からＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）仕様の情報を抽出する。ソースコード解析部２１がそれぞれの記述領域から抽出するＡＰＩ仕様の情報は、関数名、入力引数、出力引数、機能、使用するデータ型などである。ソースコード解析部２１の機能を備えるソフトウェアは、Ｄｏｘｙｇｅｎ（ｈｔｔｐ：／／ｗｗｗ．ｄｏｘｙｇｅｎ．ｊｐ／）が有名であるが、他にも同様の複数のプログラム構造解析ソフトウェアがある。

図１３は、ソースコード解析部２１によってソースコード５４から抽出されるＡＰＩ仕様の情報の例を示す図である。ＯｐｅｎＥＬに適用する場合、ＡＰＩ仕様の情報の抽出結果として、図１３に示すような、モータ関連の関数一覧を得ることができる。なお図１３は、一部を掲載している。

（Ｓ２２：ファンクションリストの生成）
次に、ステップＳ２２において、ファンクションリスト生成部２２は、ソースコード解析部２１によって抽出されたＡＰＩ仕様の情報から、オブジェクトごとのファンクションのリストを生成する。つまり、ファンクションリスト生成部２２は、抽出されたＡＰＩ仕様の情報における「関数名、引数名、機能」から、オブジェクトに相当するキーワードを抽出する。ファンクションリスト生成部２２による処理も、第１のキーワード抽出部１２と同様に、キーワードを抽出することになるが、抽出の元データが関数一覧であるため、より効率的な抽出が可能である。また、関数名は複数の単語を連結した記述となっていることが多いため、ファンクションリスト生成部２２は、関数名を分解し、複数の単語の状態でキーワード抽出を行う。なお、図１３は、抽出されたＡＰＩ仕様の情報の一部を掲載しているが、オブジェクトとして「モータ」に関する関数一覧である。図１３は、オブジェクトが「モータ」であるファンクションリストとみることができる。

図１３に示す、抽出されたＡＰＩ仕様の情報では、関数名の共通部分を抽出した場合、「ＨａｌＭｏｔｏｒ」に機能の名称が付加されたものが関数名となるパターン規則を考慮できる。日本語文章で記述される右側の「機能」の文章から、「モータ」という共通キーワードが抽出される。図１３の例では、「ＨａｌＭｏｔｏｒ」と「モータ」とがリンクできる。ランク付けされた複数候補のキーワードが得られる場合は、上位語を選択するようにする。計算機の処理では、誤った決定をする場合もあるため、人がオブジェクトの判定結果を確認して誤りがあれば訂正できる仕組みを用意しても良い。

なお図１３に関して、一般のソースコードであれば、通常、関数ごとにプログラムが記述されている。内部仕様書に対応したソースコードを実装するのであれば、必ず関数１つ１つがソースコードの中のどこかに記述される。実施の形態１のソースコードには、図１３に示す関数一覧内の全関数が記載されている。なお、関数という記載以外にＡＰＩ、ファンクションという記載もあるが、本明細書では、関数、ＡＰＩ、ファンクションは同等に取り扱っている。オブジェクトごとのファンクションのリストは、ファンクションリスト生成部２２が生成するが、ファンクションリスト生成部２２は、ＡＰＩ仕様を入力とし、関数名の一覧を生成する。図１３は関数一覧であり、ファンクションリストである。

（Ｓ２３：キーワードの抽出）
次に、ステップＳ２３において、第２のキーワード抽出部２３は、ファンクションリスト生成部２２が生成したファンクションリスト（図１３）から、主要キーワードをランク付けして抽出する。第２のキーワード抽出部２３は、オブジェクトごとのファンクションリストから、主要キーワードを選び出す。図１３の場合であれば、オブジェクトが「モータ」のファンクションリストとみることができるので、第２のキーワード抽出部２３は、図１３のリストから主要キーワードをランク付けして抽出する。

以上の処理により、要求仕様書５１、外部仕様書５２、内部仕様書５３、ソースコード５４のそれぞれの文章領域の主要キーワードが抽出される。それぞれの文章領域の主要キーワードの抽出は、図６の矢印に対応する。

外部仕様書５２に相当する「ＯｐｅｎＥＬ ２．０の仕様書」では、第１のキーワード抽出部１２によるステップＳ１２に関係する分割された領域のキーワードの例は、図１４のようになる。
図１４は、外部仕様書５２に相当する「ＯｐｅｎＥＬ ２．０の仕様書」において、複数の文章領域と、文章領域のキーワードとを示す。

ここで、例を示すために、図１５のような、仮の簡略な要求仕様書５１の章節構成（以下、目次構成と記す）を定義する。
図１５は、仮の簡略な要求仕様書５１における、複数の文章領域と、文章領域のキーワードとを示す。

さらに、仮に、図１６のような内部仕様書５３の目次構成を用意し、キーワードを設定する。
図１６は、内部仕様書５３における、複数の文章領域と、文章領域のキーワードとを示す。ソースコード５４から内部仕様書５３を自動生成するＤｏｘｙｇｅｎツールがあるが、内部仕様書５３にも、ソースコード５４にもＡＰＩ名称が記載されている。ソースコード５４の領域と内部仕様書５３の領域との対応付けのキーワードとしては、ＡＰＩ名称を採用するのが適している。対応付け処理の基本的なアルゴリズムは、各仕様書の領域、ソースコードの領域に対して、他方の領域のキーワードで検索を行い、大量に見つかるものを最も対応付けがとれると判断することができる。最近では、単純なキーワードの一致だけではなく、より対応付け処理の精度を向上できる手段があるので、これらの手段も利用できる。

なお、ＡＰＩごとにソースコードが用意されているとする。
図１７は、ソースコード５４の構成例を示す。ソースコード５４の主要キーワードとして、ＡＰＩ名称を取り上げることができる。
図１８は、内部仕様書５３に含まれるＡＰＩ名称を示す。図１８の「ＨａｌＩｎｉｔ，ＨａｌＥｘｉｔ」等がソースコード５４のキーワードと共通するキーワードである。

（Ｓ３１：領域対応情報の抽出）
以上の、図１７の形式のソースコード５４、図１６、図１８の形式の内部仕様書５３、図１４の形式の外部仕様書５２、図１５の形式の要求仕様書５１に対して、第１の対応抽出部３１ａ、第２の対応抽出部３１ｂ、第３の対応抽出部３１ｃは、各仕様書及びソースコードの領域ごとに、主要キーワードを比較して、対応する文章領域同士を結び付けて、領域対応情報を生成する。「領域対応情報」とは、ソースコード５４の領域と内部仕様書５３の領域、内部仕様書５３の領域と外部仕様書５２の領域、外部仕様書５２の領域と要求仕様書５１の領域との領域というように２つの領域同士を対応付ける情報である。図６で述べたように、第１の対応抽出部３１ａは、ソースコード５４の領域と内部仕様書５３の領域とを対応付ける。第２の対応抽出部３１ｂは、内部仕様書５３の領域と外部仕様書５２の領域とを対応付ける。第３の対応抽出部３１ｃは、外部仕様書５２の領域と要求仕様書５１の領域とを対応付ける。なお一つの領域に対して複数の領域が対応付けられてもよい。図６の製品Ｐでは、ソースコード５４の１段目の領域、内部仕様書５３の１段目、４段目の領域は、いずれもキーワードが「モータ」である。この場合、第１の対応抽出部３１ａは、ソースコード５４の１段目の領域を、内部仕様書５３の１段目、４段目の各領域と対応付ける。この場合、対応付け情報生成部３２は、キーワードのモータに関しては、対応付け情報として、要求仕様書５１〜ソースコード５４の４つの１段目から成る対応付け情報と、要求仕様書５１、外部仕様書５２、ソースコード５４の３つの１段目、内部仕様書５３の４段目からなる対応付け情報を生成する。

（第１の対応抽出部３１ａ）
第１の対応抽出部３１ａは、キーワード比較により、ソースコード５４と内部仕様書５３との各領域の対応関係を抽出する。第１の対応抽出部３１ａは、主要キーワードがＡＰＩ名称の場合は、比較的容易に、ソースコード５４の各記述領域と、内部仕様書５３の各文章領域とを対応付けできる。なお、ここで「対応付ける」とは、仕様書どうしにおいて、あるいはソースコード５４と内部仕様書５３とにおいて、一方の領域が他方のどの領域に対応づけられるかを照合し、対応付ける処理である。例を示せば、一方の１つの領域をクリックすると、ハイパーリンクが張られており、他方の１つの領域が示される場合である。ただし、「対応」は１対１対応とは限らず、一つの領域が、他方の複数の領域に対応付けられる場合も有る。第１の対応抽出部３１ａ，第２の対応抽出部３１ｂ，第３の対応抽出部３１ｃによる対応付けの結果である領域対応情報は、対応付け情報生成部３２が対応付け情報の生成に使用する。対応付け情報は、後段処理１Ｂの対応判定部４１によって使用される。
図１９は、第１の対応抽出部３１ａが、図１３のキーワードを持つソースコード５４と、図１６のキーワードを持つ内部仕様書５３とから、ソースコード５４と内部仕様書５３との領域同士の対応付けを行った例を示す。

（第２の対応抽出部３１ｂ）
第２の対応抽出部３１ｂは、キーワード比較により、内部仕様書５３と外部仕様書５２との各文書領域の対応関係を抽出する。第２の対応抽出部３１ｂでは、主要キーワードは、出現頻度に応じて選定された語彙を採用することができる。第２の対応抽出部３１ｂによる処理において、有効な判断基準としては、章、節の名称の類似性を考慮できる。上述の例からも明らかである。こうして、内部仕様書５３と外部仕様書５２との各文章領域とを効率よく対応付けることができる。
図２０は、図１６、図１８の内部仕様書５３と、図１４の外部仕様書５２との領域の対応付けの例を示す。

（第３の対応抽出部３１ｃ）
第３の対応抽出部３１ｃは、キーワード比較により、外部仕様書５２と要求仕様書５１との対応関係を抽出する。第３の対応抽出部３１ｃでも、同様に、主要キーワードは、出現頻度に応じて選定された語彙を採用することができる。ただし、元来、要求仕様書５１は、プログラムの構成は考慮されていないため、要求機能が羅列されている場合が多い。このため要求仕様書５１は、プログラムの構成的な目次構成から、はずれた目次構成になっている場合が多い。よって、要求仕様書５１は、外部仕様書５２の目次構成と１対１には対応しない可能性が高い。しかし、機能を記述する際に使用するキーワードの出現頻度で対応付け可能であると想定でき、キーワードによる分類解析は有効である。
図２１は、図１４の外部仕様書５２と、図１５の要求仕様書５１とから得られた領域の対応を示す。

（Ｓ３２：対応付け情報６１、６２、６３の生成）
ステップＳ３３において、第１の対応抽出部３１ａはソースコード５４の領域と、内部仕様書５３の領域とを対応付けた領域対応情報を生成する。同様に、第２の対応抽出部３１ｂ、第３の対応抽出部３１ｃは、２つの仕様書間の領域どうしを対応付けた領域対応情報を生成する。対応付け情報生成部３２は、第１の対応抽出部３１ａ等が生成する領域対応情報を用いて、対応付け情報を生成する。図６を参照して説明する。製品Ｐを想定する。第１の対応抽出部３１ａは、キーワードのモータによって、ソースコード５４の１段目の領域と内部仕様書５３の１段目の領域とを対応付ける領域対応情報を生成し、対応付け情報生成部３２に送信する。第２の対応抽出部３１ｂは、キーワードのモータによって、内部仕様書５３の１段目の領域と、外部仕様書５２の１段目の領域とを対応付ける領域対応情報を生成し、対応付け情報生成部３２に送信する。第３の対応抽出部３１ｃは、キーワードのモータによって、外部仕様書５２の１段目の領域と要求仕様書５１の１段目の領域とを対応付ける領域対応情報を生成し、対応付け情報生成部３２に送信する。対応付け情報生成部３２は、キーワードのモータについて、対応付け情報６１−１を生成する。製品Ｑ、Ｒについても、対応付け情報生成部３２は同様に、キーワードのモータについて、対応付け情報を生成する。なお、内部仕様書５３の４段目の「モータ」について、対応付け情報生成部３２は、要求仕様書５１、外部仕様書５２の１段目、内部仕様書５３の４段目、ソースコード５４の１段目の４領域を対応付けた対応付け情報も生成する。対応付け情報生成部３２は、対応付け情報６２−１等を対応判定部４１へ送信する。

（Ｓ３４：トレーサビリティ情報）
文章領域の対応付けについては、既存の各仕様書にトレーサビリティ情報が記載している場合があり、トレーサビリティ情報を活用することができる。図４において、トレーサビリティ情報取得部３３ａ、３３ｂ、３３ｃは、それぞれトレーサビリティ情報３３ｄ，３３ｅ，３３ｆにより、第１の対応抽出部３１ａ〜第３の対応抽出部３１ｃによる対応付けを限定する、オプション的な構成要素である。トレーサビリティ情報３３ｆは要求仕様書５１のものであり、トレーサビリティ情報３３ｅは外部仕様書５２のものであり、トレーサビリティ情報３３ｄは内部仕様書５３のものである。トレーサビリティ情報３３ｄ、３３ｅ、３３ｆは補助記憶装置９０２ａに記憶されており、トレーサビリティ情報取得部３３ａ、３３ｂ、３３ｃは、補助記憶装置９０２ａから読み出す。

（Ｓ３４：相互関係判定部３４）
また、図４では、相互関係判定部３４によるステップＳ３４を付加している。相互関係判定部３４は、複数キーワードの出現場所の近傍レベルからキーワード間の相関関係を判定する。これは、単純に文書領域に特定のキーワードが含まれる、含まれないということで、文章領域どうしの類似性を判断するものではない。相互関係判定部３４は、複数のキーワードが比較的近くの場所に現れるということで、関連の強いキーワード群として扱うものであり、必ずしも、キーワード群の全てが現れなくても、そのうちのいくつかのキーワードが含まれていれば、類似箇所として判定することが可能になる。つまり、相互関係判定部３４は、一方の文章領域に存在するキーワード群と、他方の文章領域に存在するキーワード群との類似性から、一方の文章領域と他方の文書領域との類似性を判定することが可能である。これも、上述した文書間の類似性を調べる手法の１つとなる。相互関係判定部３４は前段処理１Ａにはオプション的な機能であるが、相互関係判定部３４によって、文書領域どうしの類似性を効果的に調べることができる。

＊＊＊後段処理１Ｂの動作の説明
次に、図９、図２２を参照して後段処理１Ｂの動作を説明する。
図９は、図５のブロック図に対応する形式の処理フローである。
図２２は、後段処理１Ｂの処理フローであり、図９に対応する処理には図９のステップ番号を付している。

後段処理１Ｂにより、新規に開発する製品Ｚの要求仕様書、外部仕様書、内部仕様書、ソースコードに関して、既存の類似製品のものからテンプレートを作成する。以下の説明では、既存の類似製品としてＰ、Ｑ、Ｒの３製品があり、それぞれ各種仕様書とソースコードが存在する。

製品Ｐ、Ｑ、Ｒの各文章領域の対応付けが前段処理１Ａにより行われたものとする。後段処理１Ｂでは、対応付けされた複数の文章領域を含むＰ、Ｑ、Ｒ同士を比較する。既に、各文章領域にて主要キーワードを抽出されている（ステップＳ１２、ステップＳ２３）ので、Ｐ、Ｑ、Ｒの文書間にてお互いの主要キーワードの出現頻度を検索で算出し、類似度を求める。なお、複数文書間にて、それぞれの文書がもつ主要キーワード群を照らし合わせて類似度を求める以外にも、文書を要約してその要約文の類似性を求めるなど、文書間の類似性を調べる既存の手法は様々にあり、こうした手法を用いることも可能である。そして、その類似度が高い領域が存在するかどうかを確認し、製品Ｐ、Ｑ、Ｒのそれぞれにて共通的に存在する領域を見つけ出し、今回の新製品の仕様書、ソースコードのためのテンプレート採用箇所とする。詳細を以下に説明する。

図９のステップに沿って説明する。

（Ｓ４１：対応判定）
ステップＳ４１において、対応判定部４１は以下の処理を行う。
図２３は、図６の要求仕様書５１〜ソースコード５４の１段目の領域を「モータ」で対応付ける対応付け情報６１−１を示す。図６、図９に示すように、対応判定部４１には、製品Ｐ、Ｑ、Ｒの対応付け情報が入力データとして入力される。ここで製品Ｐ、Ｑ、Ｒの対応付け情報は、図６で説明したものである。対応判定部４１は、Ｐ，Ｑ，Ｒの製品の中に、類似領域グループが存在するか判定する。対応判定部４１には、図６の製品Ｐについての対応付け情報６１−１、製品Ｑについての対応付け情報６２−１、製品Ｒについての対応付け情報６３−１等が入力されている。対応付け情報６１−１は、製品Ｐの要求仕様書５１〜ソースコード５４の１段目の領域を対応付ける情報である。同様に、対応付け情報６２−１は製品Ｑの要求仕様書５１〜ソースコード５４の１段目の領域を、対応付け情報６３−１は製品Ｒの要求仕様書５１〜ソースコード５４の１段目の領域を対応付ける情報である。対応判定部４１は、対応付け情報６１−１によって対応付けが示される領域グループ６１Ｇ−１を、メモリ９０２ｂから取得する。領域グループ６１Ｇ−１は、製品Ｐの要求仕様書５１〜ソースコード５４の１段目の領域からなる。同様に、対応判定部４１は、領域グループ６２Ｇ−１、６３Ｇ−１を、メモリ９０２ｂから取得する。領域グループ６２Ｇ−１、６３Ｇ−１は、それぞれ、製品Ｑ、製品Ｒの要求仕様書５１〜ソースコード５４の１段目の領域からなる。

対応判定部４１では、カウント部４１ａが製品Ｐ，Ｑ，Ｒの領域グループ６１Ｇ−１、６２Ｇ−１、６３Ｇ−１の領域グループの類似関係を判定する。つまり、前段処理１Ａでは、一つの製品を単位として、ソースコード５４、内部仕様書５３、外部仕様書５２、要求仕様書５１の各領域について、図６における横の類似関係を判定する。対応判定部４１では、複数の製品のそれぞれの領域グループについて、図６における縦の類似関係を判定する。カウント部４１ａは、前段処理１Ａで第１のキーワード抽出部１２、第２のキーワード抽出部２３が抽出したキーワードと、キーワードが抽出された領域との対応関係の情報をメモリ９０２ｂから読み取る。つまり、対応判定部４１は、領域グループ６１Ｇ−１、６２Ｇ−１、６３Ｇ−１をメモリ９０２ｂから取得している。これらはキーワードの「モータ」が同一であるので、「モータ」を特徴点として互いに類似する類似領域グループである。しかし、対応判定部４１にはこれらが類似領域グループであるかわからない。そこで、対応判定部４１はカウント部４１ａを用いて領域グループ６１Ｇ−１、６２Ｇ−１、６３Ｇ−１が類似領域グループかを判定する。カウント部４１ａは、領域グループ６１Ｇ−１等の各領域のキーワードをカウントすることで、領域グループ６１Ｇ−１、６２Ｇ−１、６３Ｇ−１が、「モータ」を特徴点として互いに類似する類似領域グループであると判定する。

図７は、対応判定部４１がカウント部４１ａを用いた場合の判定結果である。図７は、特徴点を同じとして互いに類似する類似領域グループの存在の有無を製品ごとに示す。図７の「モータ」の行は、類似領域グループである領域グループ６１Ｇ−１、６２Ｇ−１、６３Ｇ−１が製品Ｐ、Ｑ、Ｒに存在することを示す。「ジャイロセンサ」の行は、類似領域グループである「領域グループ６１Ｇ−２、６２Ｇ−２」（図６）が製品Ｐ、Ｑに存在することを示す。「トルクセンサ」の行は、類似領域グループである「領域グループ６１Ｇ−３、６３Ｇ−２」（図６）が製品Ｐ、Ｒに存在することを示す。

上記のように、対応判定部４１がカウント部４１ａを用いる場合、カウント部４１ａがキーワードをカウントすることで、製品Ｐ，Ｑ，Ｒの各領域グループを類似領域グループとして対応づけることができる。しかし、カウント部４１ａの使用に限らず、対応判定部４１は、相関関係の強い複数キーワード、文章等の類似度によって、関連のある文書領域を抽出してもよい。相関関係の強い複数キーワードの例として、モータに関連してデバイス、速度、ブレーキというような複数キーワードがある。対応判定部４１がデバイス、速度、ブレーキを含む文章領域を製品Ｐ，Ｑ，Ｒそれぞれの書類の領域として抽出すれば、１つのキーワードで選んだ文章領域よりも、より類似的な内容が書かれた領域であり、関連性がある高いと考えることができる。

また、文章の構造を解析する文章解析部４１ｂが要約を作成してよい。図６の領域グループ６１Ｇ−１、６２Ｇ−１を例に説明する。文章解析部４１ｂは、領域グループ６１Ｇ−１、６２Ｇ−１における内部仕様書５３の領域と、外部仕様書５２の領域と、要求仕様書５１の領域とのうちの少なくともいずれかの領域の要約を生成する。文章解析部４１ｂは、領域グループ６１Ｇ−１、領域グループ６２Ｇ−１の要約どうしを比較することによって、領域グループ６１Ｇ−１と領域グループ６２Ｇ−１とが互いに類似する類似領域グループか判定する。要約どうしの比較は同じ種類の仕様書どうしが好ましいが、文章解析部４１ｂは、異なる種類の仕様書の要約どうしを比較してもよい。

（Ｓ４２：重要度の判定）
次に、ステップＳ４２において、重要度判定部４２は、対応判定部４１の作成した図７を参照する。重要度判定部４２は、図７において、「モータ」に関する類似領域グループが製品Ｐ，Ｑ，Ｒ全てに存在していると確認し、「モータ」を特徴点とする類似領域グループの重要度は高いと判定する。また、重要度判定部４２は、図７の「ジャイロセンサ」、「トルクセンサ」に関する類似領域グループが、製品Ｐ，Ｑ、製品Ｐ，Ｒに存在すると確認する。「ジャイロセンサ」を特徴点とする類似領域グループ、「トルクセンサ」を特徴点とする類似領域グループの重要度は、中程度と判定する。

（Ｓ４３：テンプレートの出力）
ステップＳ４３において、テンプレート出力部４３は、製品Ｐ，Ｑ，Ｒの３つに存在する確認された、モータを特徴点とする類似領域グループについて、製品Ｐの類似領域グループを出力する。なお、「モータ」を特徴点とする類似領域グループであれば、製品Ｑあるいは製品Ｒの類似領域グループを出力しても良い。

図２４は、要求仕様書のテンプレートの例を説明する図である。
図２５は、外部仕様書５２のテンプレートの例を説明する図である。
図２６は、内部仕様書５３のテンプレートの例を説明する図である。
図２７は、ソースコードのテンプレートの例を説明する図である。

（Ｓ４４：空欄の作成）
最後に、ステップＳ４４において、空欄作成部４４は、テンプレート出力部４３によって出力された各テンプレート中に、製品機種名称、モータ等のデバイスの型番、製品名など、製品Ｐ，Ｑ，Ｒに独自な記載箇所があるか確認する。有る場合は、その箇所を空欄に修正し、テンプレートの利用の際に、新たに入力可能にする。

図２８は、各文章領域の主要キーワードとして抽出できたものを表形式で記載したサンプルを示す。図２８は、主要キーワードをもつ文章領域が、製品Ｐ、Ｑ、Ｒのそれぞれの要求仕様書５１、外部仕様書５２、内部仕様書５３、及びソースコード５４に存在するかどうかを整理した図である。文章領域が３製品に共通していれば、新製品用のテンプレートとして採用する候補になる。また、２製品にのみ含まれる場合には、中程度の候補となり、１つの製品にしかなければ、候補としては採用しにくくなる。これは上記の図７で説明した内容であり、重要度判定部４２が判定する。

図２９は、後段処理にて共通的なオブジェクトと関数を抽出する処理を示した説明図である。

以上に説明したテンプレート生成装置１は、前段処理１Ａでは、単一製品について、ソースコード５４のオブジェクトや関数の記述に対応する仕様書類記述を、内部仕様書５３、外部仕様書５２、要求仕様書と遡って対応付けを行う。テンプレート生成装置１は、各設計情報部品の関連性を明確にするために、対応箇所ごとに整理を行う。テンプレート生成装置１は、後段処理１Ｂでは、複数製品の書類間で対応箇所の比較を行い、重要で共通的な記述を、テンプレートの材料として選択する。

＊＊＊実施の形態１の効果の説明＊＊＊
（１）実施の形態１のテンプレート生成装置１は、前段処理１Ａと後段処理１Ｂとを実行することにより、ソースコードから内部仕様書、外部仕様書、要求仕様書へと設計の上流へ遡って文章領域の対応付けを行うので、類似製品の、要求仕様書、外部仕様書、内部仕様書、ソースコードのテンプレートを作成できる。
（２）テンプレート生成装置１によれば、サンプル文書のように、ベースとなる仕様書、ソースコードが自動生成できる。よって、開発プロジェクトの参加設計者が開発製品の設計技術に熟達していない場合であっても、ベースとなる共通的なサンプル文書を用意することができる。よって、効率的に仕様書作成ができる。
（３）実施の形態１に示したように、既存の複数製品の要求仕様書５１、外部仕様書５２、内部仕様書５３及びソースコード５４をベースに、共通的な文章領域を中心として類似製品の、ソースコード、内部仕様書、外部仕様書、要求仕様書の各テンプレートを生成する。よって、生成された各テンプレートを使用することで、開発者は、新製品の要求仕様書、外部仕様書、内部仕様書、ソースコードについて、比較的重要な設計記述を中心に記載ができる。
（４）また、あまり重要でないオプション的な処理の記述が取り除かれたテンプレートが生成されるので、開発は、効率良い編集作業ができる。

＊＊＊他の構成＊＊＊
図３０は、処理回路９９を示す図である。本実施の形態ではテンプレート生成装置１の「部」の機能はソフトウェアで実現されるが、変形例として、テンプレート生成装置１の「部」の機能がハードウェアで実現されてもよい。つまり、処理回路９９によって、前述したプロセッサ９０１として示すテンプレート生成装置１の「部」の機能、及び「記憶装置」の機能を実現する。処理回路９９は信号線９９ａに接続している。処理回路９９は、テンプレート生成装置１の「部」の機能及び「記憶装置」の機能を実現する専用の電子回路である。処理回路９９は、具体的には、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ・Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ・Ｓｐｅｃｉｆｉｃ・Ｉｎｔｅｇｒａｔｅｄ・Ｃｉｒｃｕｉｔ）、又は、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ・Ｇａｔｅ・Ａｒｒａｙ）である。

テンプレート生成装置１は、処理回路９９を代替する複数の処理回路を備えていてもよい。これら複数の処理回路により、全体として、テンプレート生成装置１の「部」の機能が実現される。それぞれの処理回路は、処理回路９９と同じように、専用の電子回路である。

別の変形例として、テンプレート生成装置１の機能がソフトウェアとハードウェアとの組合せで実現されてもよい。すなわち、テンプレート生成装置１の一部の機能が専用のハードウェアで実現され、残りの機能がソフトウェアで実現されてもよい。

プロセッサ９０１、記憶装置９０２及び処理回路９９を、総称して「プロセッシングサーキットリ」という。つまり、テンプレート生成装置１の「部」の機能及び記憶装置は、プロセッシングサーキットリにより実現される。

「部」を「工程」又は「手順」又は「処理」に読み替えてもよい。また、「部」の機能をファームウェアで実現してもよい。つまり、テンプレート生成装置１の動作はテンプレート作成プログラム、テンプレート作成方法として把握できる。また、「部」の機能は、テンプレート作成プログラムを格納する記録媒体して実現することもできる。

実施の形態２．
＜要求仕様書５１と外部仕様書５２との対応関係の異なる抽出例＞
以下に実施の形態２を説明する。なお、以下の実施の形態２、３では、実施の形態１のテンプレート生成装置１を使用する。実施の形態２、３では、実施の形態１に対して、前段処理１Ａに入力されるデータが実施の形態１と異なる。

本実施の形態２では、要求仕様書５１の例として、公開されているシステム開発文書品質研究会（ＡＳＤｏＱ）人材育成部会（ｈｔｔｐ：／／ａｓｄｏｑ．ｊｐ／）による「ＳＷＰ１−Ｄ３０１ ムーブレボ通報システム ソフトウェア要求仕様書」（著者：山本雅基氏）（ｈｔｔｐ：／／ａｓｄｏｑ．ｊｐ／ｒｅｓｅａｒｃｈ／ｊｉｎｚａｉ．ｈｔｍｌ）を例として説明を行う。このソフトウェア要求仕様書を以下、要求仕様書５１−２と記す。要求仕様書５１−２は、「ムーブレボ」という仮想の電動一人乗り移動体（自動走行も可能な高機能な車椅子）を想定している。要求仕様書５１−２は、さらに、その移動体に搭載される複数の組込みシステムの一つとして、異常が発生した時にヘルプセンターへ異常を知らせる「通報システム」に関する。

図３１、図３２は、要求仕様書５１−２の目次を示す。要求仕様書５１−２の目次は、図３１、図３２との２図に分けた。図３１の最後の「３．１０ 通報地値（出力） ９」が、図３２の上段の「４ 開発制約要求 １０」につながる。右端の数字はページ数を示す。

一般に、要求仕様書と外部仕様書との関連性は、要求仕様書における機能に対する要求の記述と、外部仕様書の関数記述とが、最も深く対応づけられる。以下で全体構成を順に確認し、機能に対する要求にあたる箇所を示す。以下、図３１，図３２を参照して説明する。

「１．はじめに」の章では、１．１ 本書の目的、１．２ 用語定義、１．３ 関連文書があり、「１．はじめに」の章は、全般的に文書の前置きとしての記載であり、機能関連の記述は特にない。

実際の要求仕様書の「２．ソフトウェア概要」の章では、２．１ 本ソフトウェアの概要、２．３ 外部入出力値の概要、２．４ 通報システムが取る状態、２．５ 起動と終了の各節に、機能関連の記述が分散して含まれている。ただし、機能を詳細に記述している章は、後続であるため、本章の記載はあくまで概要レベル、あるいは、機能記述の補足情報レベルで留まっていると言える。

「３．入出力値の定義」の章では、機能を詳細に定義する際の各種数値条件について記載があり、機能についての補足情報の記述が含まれているといえる。すなわち、個々の機能を記述する際に、必要に応じてこれらの数値条件を参照することになる。

「４．開発制約要求」の章では、要求仕様書５１−２の要求条件として参照すべき関連文書が記載されており、特に機能関連の記述と結びつくものではない。

「５．機能要求」の章では、直接、個々の機能についての記述が列挙されている。「５．機能要求」の章は、外部仕様書５２の関数記述に直接に対応付けられる。ただし、必ずしも全ての外部仕様書５２の主要関数に１対１で対応がとれる保証はない。機能自体が複数の関数に分散して実装される可能性があるからである。

「６．効率性要求」の章では、実装上の制約が記載されている。「６．効率性要求」の章は、特に機能関連の記述と結びつくものではない。

「７．保守・移植性要求」の章では、プログラムを実装する際のコーディング上の留意事項が記載されている。「７．保守・移植性要求」の章は、特に機能関連の記述と結びつくものではない。

「８．信頼性要求」の章では、試験要件が記載されており、特に機能関連の記述と結びつくものではない。

次に、以上の要求仕様書５１−２の機能関連記述を分析して、仮に要求仕様書５１−２に対する外部仕様書５２の簡略な目次構成案を策定してみると、図３３のようになる。

図３３は、要求仕様書５１−２の簡略な目次構成を示す。図３３の「１．はじめに」の章では、外部仕様書５２の位置づけが説明される。

「２．概要」の章では、要求仕様書５１−２からもたらされる目的や機能の概要が記載される。また、用語定義や関連文書など、外部仕様書５２を外部から規定する情報も記載される。

「３．ソフトウェア全体構成」の章では、要求仕様では現れない別の観点での設計情報が記載される。実装するにあたっての最適なソフトウェア全体構成が記載される。時間的な性能、使用するメモリ等の資源の効率的使用、コーディング設計の容易性、プログラムの保守性や再利用性などが考慮され、ソフトウェア構成が設計される。次章の関数ＡＰＩにおける関数が、タスク、スレッド、コールバック、各種ハンドラなど、どのように呼び出されるのかも、「３．ソフトウェア全体構成」から規定される。実際の要求仕様書５１−２の「図１ 状態遷移」を参照すると、電源が入って起動処理が実行された後は、正常状態で各種機能を実行しながらメインループ処理が動作すると想定される。このメインループ中にボタン操作や電圧チェック判定などで必要な機能を呼び出して処理を行い、メインループ処理を継続する。各種機能で異常が発生した場合に、異常状態に移行して電源が切断される。

「４．関数ＡＰＩ」の章では、個々の機能に対応する表層の全関数について、インタフェース仕様が記載される。
本実施の形態の個々の機能では、
要求仕様書５１−２の「５．機能要求」から、
５．１ 起動処理、
５．２ 移動速度表示機能、
５．３ バッテリ残量表示機能、
５．４ 走行可能距離表示機能、
５．５ システム状態表示機能、
５．６ Ｇ値超過通報機能、
５．７ 警報ボタン押下時通報機能、
５．８ 電圧低下時終了機能
のそれぞれについて、関数が用意されると想定される。
ここでは、「４．関数ＡＰＩ」の章において、４．１から４．８までの節番号を、これらの各機能について順に付加する。
また、上述したメインループ内から、
５．２ 移動速度表示機能、
５．３ バッテリ残量表示機能、
５．４ 走行可能距離表示機能、
５．５ システム状態表示機能、
５．６ Ｇ値超過通報機能、
５．７ 警報ボタン押下時通報機能
に相当する関数が呼び出される。

図３３の「５．外部設計補足情報」の章では、「４．関数ＡＰＩ」で説明した各関数を実装するにあたって、補足となる数値や留意点等が記載される。

以上の要求仕様書５１−２と外部仕様書５２について、実施の形態１のテンプレート生成装置１を適用した処理を以下に説明する。

要求仕様書５１−２、外部仕様書５２の目次構成は上述通りであるので、分割部１１は、容易に文書データを分割出力できる。

次に、第１のキーワード抽出部１２は、主要キーワードを、以下のように抽出できる。
要求仕様書５１−２については、上述した機能関連の章節に限定して、図３４に示す。
図３４は、要求仕様書５１−２から抽出された主要キーワードである。

外部仕様書５２については、「１．はじめに」、「２．概要」「３．ソフトウェア全体構成」の章は、特に頻出する主要キーワードもほとんど現れない。これらは、特に対応付けをとるまでもなく、前置き的な文章領域として位置付けられる。

「４．関数ＡＰＩ」の章については、上述したように各種機能関数が項目別に記載されている。よって、個々の関数ごとに要求仕様書５１−２側の主要キーワードが良く現れる箇所に、対応付けることができる。今回の例を図３５に示す。つまり、図３５は、第１の対応抽出部３１ａによる処理結果である。

基本的に文書間の各文章領域の対応関係付けは、主要キーワードを中心に行うが、オプション的な補助手段として、日本語文章として詳細に文章構造解析を行って、意味論的に類似性を調べて対応付けを行うことで、より精度の高い対応付けを行うことができる。

実施の形態１と同様に、外部仕様書５２から内部仕様書５３、ソースコード５４と各関数に対応付けして作成している想定であり、実施の形態１と同様な対応付けができる。

以上、実施の形態２で示したように、一般にソースコードの各関数に対応する仕様書の文章領域は、内部仕様書や外部仕様書を中心に１対１に対応する記述箇所となる場合が多い。しかし、要求仕様書の場合、要求記載項目が必ずしも、各関数に１対１に対応しないことが多い。このような多対多対応の仕様書の対応付けの整理も、実施の形態１で述べたテンプレート生成装置１によれば効率的に実行できる。よって、共通で必要な設計情報を盛り込んだテンプレートの自動生成ができる。

実施の形態３．
＜要求仕様書５１と外部仕様書５２との対応関係の別の抽出例＞
次に、日本医師会総合政策研究機構により策定、開発、公開されているオープンソースプロジェクトであるＯＲＣＡ ＰＲＯＪＥＣＴにおける日医標準レセプトソフト（ｈｔｔｐｓ：／／ｗｗｗ．ｏｒｃａ．ｍｅｄ．ｏｒ．ｊｐ／ｒｅｃｅｉｐｔ／）を取り上げて説明する。本プロジェクトでは、仕様書類、ソースコードの公開が充実化されている。システム全体は、データベースシステムを含む大規模なものであるが、クライアント端末装置からレセプト関連業務の処理を行うためのＷｅｂ ＡＰＩのソフトウェア実装部分を、実施の形態１で述べたテンプレート生成装置１の適用の対象とする。

要求仕様書５１相当の技術文書として、システム全体の基本仕様書（ｈｔｔｐ：／／ｆｔｐ．ｏｒｃａ．ｍｅｄ．ｏｒ．ｊｐ／ｐｕｂ／ｄａｔａ／ｒｅｃｅｉｐｔ／ｔｅｃ／ｏｒｃａ＿ｂｄ＿ｂｓｓ＿０１０．ｐｄｆ）を取り上げる。さらに、外部仕様書５２相当の技術文書として、日医標準レセプトソフトＡＰＩ仕様（ｈｔｔｐｓ：／／ｗｗｗ．ｏｒｃａ．ｍｅｄ．ｏｒ．ｊｐ／ｒｅｃｅｉｐｔ／ｔｅｃ／ａｐｉ／ｏｖｅｒｖｉｅｗ．ｈｔｍｌ＃ｖｅｒ４７０）を取り上げる。これは、公開ホームページ上で１冊のまとまった文書としての体裁ではなく、ＡＰＩ一覧に各ＡＰＩの詳細説明文書がリンクされたハイパーテキスト形態で参照できるようになっているが、テンプレート生成装置の入力データとして、ＡＰＩ一覧と各ＡＰＩの詳細説明文書を１冊の文書データとして取り扱う。

また、このＡＰＩはクライアント端末からデータベースのあるサーバへのＷｅｂ ＡＰＩとして実装されており、実際にデータベースを操作する内部処理はＡＰＳと呼ばれるＣＯＢＯＬモジュールが行う。したがって、これら各ＡＰＩに相当するソースコードはＣＯＢＯＬ実装となる。本ソフトではこのＣＯＢＯＬ実装の内部仕様書５３がなく、直接にソースコードを読み解く必要がある（現状のソースコードではＤｏｘｙｇｅｎ等での内部仕様書の生成もできない）。したがって、この例では、内部仕様書５３はＡＰＩ一覧に沿ったものが仮に作られたと想定して説明する。

図３６は、外部仕様書５２に相当するＷｅｂ ＡＰＩの一覧を示す。

図３７に、Ｗｅｂ ＡＰＩのソースコードファイル一覧を示す。右端に対応ＡＰＩとして想定できるものを付記している。正確な対応付けについては、外部仕様書に相当するＡＰＩ仕様に、詳細なレスポンス情報やサンプルソースコードが記載されているため、前段処理１Ａによってキーワードを中心に類似度を求めれば可能になる。

図３７は、ソースコード５４と外部仕様書５２との対応付けをいきなり示しているが、内部仕様書５３と外部仕様書５２との対応付けについては、上記のＣＯＢＯＬのソースコード中に記載されたＡＰＩごとに記載された内部仕様書５３が存在するとして、ＣＯＢＯＬのソースコードに１対１に対応した形態となる。したがって、特にこれ以上の記載はしない。

次に、要求仕様書５１相当の基本仕様書と外部仕様書５２との対応付けについてみることにする。
図３８は、基本仕様書の主要目次項目を示す。

キーワード的に、患者、予約、病名などが、外部仕様書５２に相当するＡＰＩ仕様の各項目名と対応していることが容易にわかる。同様に、前段処理１Ａにより、要求仕様書５１と外部仕様書５２との各領域の対応付けを決めることが可能である。上述の要求仕様書５１−２の場合と同様に、多対多の対応付けがなされる可能性がある。

注意すべき点は、以下である。要求仕様書５１に記されているシステム動作環境、ネットワーク構成等の記述箇所は、外部仕様書５２との対応付けからは除外される場合がある。しかし、記述内容としては重要であるため、複数製品の要求仕様書５１にてほぼ共通に記載されていれば、その記載箇所を要求仕様書５１のテンプレート生成部分として採用するべきである。

ここまででは、前段処理１Ａを中心に記載した。「日医標準レセプトソフトの場合でも、特に複数製品分の設計文書があるわけではないが、後段処理１Ｂについても、実施の形態１の場合と同様に適用が可能である。

このように、実施の形態１、２は、組込ソフトウェア分野に該当するが、実施の形態３のように、医療分野のアプリケーションソフトウェア分野でも、同様にテンプレート生成装置１が適用できることを説明した。

テンプレート生成装置１は、ソフトウェア設計について適用する例で説明した。ハードウェア設計についても、ハードウェア設計データとしてハードウェア設計記述言語による実装がソフトウェアのプログラム実装と類似している。このため、テンプレート生成装置１は、ハードウェア設計にも適用できる。また、最終的なプログラム相当の記述言語（データ記述言語、仕様記述言語、アーキテクチャ記述言語、システムレベル記述言語など）で書かれた実装が存在するものであれば、何にでも適用できる。例としては、ＨＴＭＬ、ＸＭＬ、ＪＡＶＡ（登録商標）スクリプト等で実装されるＷｅｂホームページがある。

１ テンプレート生成装置、１Ａ 前段処理、１Ｂ 後段処理、１１ 分割部、１２ 第１のキーワード抽出部、２１ ソースコード解析部、２２ ファンクションリスト生成部、２３ 第２のキーワード抽出部、３１ａ 第１の対応抽出部、３１ｂ 第２の対応抽出部、３１ｃ 第３の対応抽出部、３２ 対応付け情報生成部、３３ａ，３３ｂ，３３ｃ トレーサビリティ情報取得部、３３ｄ，３３ｅ，３３ｆ トレーサビリティ情報、３４ 相互関係判定部、４１ 対応判定部、４１ａ カウント部、４１ｂ 文章解析部、４２ 重要度判定部、４３ テンプレート出力部、４４ 空欄作成部、５１ 要求仕様書、５１−２ 要求仕様書、５２ 外部仕様書、５３ 内部仕様書、５４ ソースコード、６１−１，６１−２，６１−３ 対応付け情報、６２−１，６１−２ 対応付け情報、６３−１，６３−２ 対応付け情報、６１Ｇ−１，６２Ｇ−１ 領域グループ、７０ テンプレート群、９９ 処理回路、９９ａ 信号線、９０１ プロセッサ、９０２ 記憶装置、９０２ａ 補助記憶装置、９０２ｂ メモリ、９０３ 入力ＩＦ、９０４ 出力ＩＦ、９１０ 第１抽出部、９２０ 第２抽出部、９３０ 生成部、９４０ 決定部。

Claims (8)

1. いずれも電子データである一つの製品の要求仕様書、外部仕様書、内部仕様書を複数の領域に分割し、各領域からキーワードを抽出する第１抽出部と、
   複数の記述領域である複数の領域からなる前記製品の電子データであるソースコードからオブジェクトごとにファンクションリストを生成し、前記ファンクションリストからキーワードを抽出する第２抽出部と、
   抽出されたキーワードを用いて、前記ソースコードの領域と、前記内部仕様書の領域と、前記外部仕様書の領域と、前記要求仕様書の領域との４領域の対応付けを示す対応付け情報を製品ごとに生成する生成部と、
   複数の製品の中に、前記対応付け情報で対応付けが示される４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定し、存在する場合に、いずれかの前記類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用するかどうか決定する決定部と
   を備えるテンプレート生成装置。
2. 前記生成部は、
   抽出されたキーワードを用いて、
   前記ソースコードの領域と前記内部仕様書の領域とを対応付け、前記ソースコードの領域に対応付けられた前記内部仕様書の領域と前記外部仕様書の領域とを対応付け、前記内部仕様書の領域を介して前記ソースコードの領域に対応付けられた前記外部仕様書の領域と前記要求仕様書の領域とを対応付けることにより、前記ソースコードの領域と、前記内部仕様書の領域と、前記外部仕様書の領域と、前記要求仕様書の領域との４領域を対応付ける請求項１に記載のテンプレート生成装置。
3. 前記決定部は、
   各製品の前記領域グループに含まれるキーワードであって、前記第１抽出部と前記第２抽出部とが抽出したキーワードである抽出キーワードを用いて、前記類似領域グループが存在するか判定する請求項１または請求項２に記載のテンプレート生成装置。
4. 前記決定部は、
   同一の前記抽出キーワードの出現頻度を用いて、前記類似領域グループが存在するか判定する請求項３に記載のテンプレート生成装置。
5. 前記決定部は、
   前記領域グループにおける前記内部仕様書の領域と、前記外部仕様書の領域と、前記要求仕様書の領域とのうちの少なくともいずれかの領域の要約を生成し、要約を比較することによって、前記類似領域グループが存在するか判定する請求項１または請求項２に記載のテンプレート生成装置。
6. 前記決定部は、
   互いに類似する前記類似領域グループが存在する製品の個数に基づいて、いずれかの前記類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用することを決定する請求項１から請求項５のいずれか一項に記載のテンプレート生成装置。
7. コンピュータに、
   いずれも電子データである一つの製品の要求仕様書、外部仕様書、内部仕様書を複数の領域に分割し、各領域からキーワードを抽出する処理、
   複数の記述領域である複数の領域からなる前記製品の電子データであるソースコードからオブジェクトごとにファンクションリストを生成し、前記ファンクションリストからキーワードを抽出する処理、
   抽出されたキーワードを用いて、前記ソースコードの領域と、前記内部仕様書の領域と、前記外部仕様書の領域と、前記要求仕様書の領域との４領域の対応付けを示す対応付け情報を製品ごとに生成する処理、
   複数の製品の中に、前記対応付け情報で対応付けが示される４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定し、存在する場合に、いずれかの前記類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用するかどうか決定する処理、
   を実行させるためのテンプレート生成プログラム。
8. コンピュータが、
   いずれも電子データである一つの製品の要求仕様書、外部仕様書、内部仕様書を複数の領域に分割し、各領域からキーワードを抽出し、
   複数の記述領域である複数の領域からなる前記製品の電子データであるソースコードからオブジェクトごとにファンクションリストを生成し、前記ファンクションリストからキーワードを抽出し、
   抽出されたキーワードを用いて、前記ソースコードの領域と、前記内部仕様書の領域と、前記外部仕様書の領域と、前記要求仕様書の領域との４領域の対応付けを示す対応付け情報を製品ごとに生成し、
   複数の製品の中に、前記対応付け情報で対応付けが示される４領域からなる領域グループであって、製品を異にして互いに類似する領域グループである複数の類似領域グループが存在するか判定し、存在する場合に、いずれかの前記類似領域グループの４領域を、要求仕様書、外部仕様書、内部仕様書、ソースコードの各テンプレートに採用するかどうか決定する
   テンプレート生成方法。

Images