JP2013008237A - 関連情報抽出プログラム、関連情報抽出方法及び関連情報抽出装置 - Google Patents

Abstract

【課題】トレース情報を精度よく抽出する。
【解決手段】要素情報取得部１２が、要件定義書に含まれる要件要素情報と要件要素項目情報を取得するとともに、基本設計書に含まれる設計要素情報と設計要素項目情報を取得し、設計要素候補判定部１８が、取得した設計要素項目情報のうち積集合が空集合でない組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する。そして、トレース候補判定部１６は、要素情報取得部１２が取得した要件要素情報の１つを抽出し、その要件要素情報が有する要件要素項目情報と和集合とを比較して、要件要素項目情報が和集合に所定割合以上（閾値以上）含まれていた場合に、要件要素項目情報に対応する要件要素情報と和集合に対応する複数の設計要素情報との組をトレース情報として抽出する。
【選択図】図２

Description

本件は、関連情報抽出プログラム、関連情報抽出方法及び関連情報抽出装置に関する。

従来より、ソフトウェア開発では、顧客の要求を業務要件やシステムの機能要件として要件定義書に定義する工程（要件定義工程）と、システムの仕様や機能構成を基本設計書として定義する工程（基本設計工程）と、が行われている。要件定義書には、機能、概念データ、画面、帳票、インタフェースについての要件情報があり、基本設計書には、機能、論理テーブル、画面、帳票、インタフェースについての設計情報がある。

ソフトウェア開発では、業務要件に変更が生じた場合に、その変更が設計書のどの機能・仕様に影響を与えるかを特定することや、設計書の内容に業務要件が漏れなく反映されているか否かを検証することが重要である。そのため、業務要件に変更が生じた場合に、要件定義工程と基本設計工程に生じる影響を分析する技術が必要とされている。

影響分析を行うためには、要件定義工程の成果物と基本設計工程の成果物の間で、基本設計書の個々の設計内容がどの要件に基づいて設計が行われたのかという関連情報（トレース情報）を定義しておく必要がある。この場合、要件定義書と基本設計書間で網羅性検証や影響分析を効率的に行うことが重要である。また、影響分析には、個々の要件情報（以下、「要件要素情報」と呼ぶ）と個々の設計情報（以下、「設計要素情報」と呼ぶ）との間のトレース情報の抽出が必要であり、正確なトレース情報の抽出が重要である。

しかるに、現実の開発現場では、要件定義書内の要件情報と基本設計書内の設計情報の間で効率的な網羅性検証や影響分析を行うのに必要なトレーサビリティを確保するための、両情報の正確な対応付けができていない。両情報間のトレース情報を抽出するためには、本来はそれぞれの内容を理解することが必要である。しかしながら、現在の処理装置の言語処理能力及び意味処理能力では、その内容を理解して要件要素情報と設計要素情報を１対１対応で抽出することができていない。このため、通常は、近似的な手法でトレース情報の候補を抽出して優先度を付けている。例えば、非特許文献１では、要件定義書や設計図などの中間生成物間の依存関係のうち、ＵＭＬ図とその構成要素の依存関係の自動生成法について提案している。この自動生成法では、ＵＭＬ図とその構成要素間の名称の類似性を利用している。

小谷正行、落水浩一郎：「UML記述の変更波及解析に利用可能な依存関係の自動生成」 情報処理学会論文誌Vol.49 Ｎｏ．7, 2008

しかしながら、要件定義書で定義している要件情報は、基本設計書で設計情報として定義する際に詳細化されるため、要件要素情報と設計要素情報では作成粒度が異なる。すなわち、要件定義書で定義された要件要素情報（Ａとする）が、基本設計書では複数の設計要素情報（例えば、Ａ’、Ａ”の２つ）に分かれる場合がある。このような場合に、従来のように名前の類似度を用いてトレース情報の候補を抽出することとすると、情報Ａと情報Ａ’、Ａ”の名前の類似度が低い場合には情報Ａのトレース情報の候補を正確に抽出できないおそれがあった。

そこで本件は上記の課題に鑑みてなされたものであり、要件要素情報と設計要素情報との間の関連性を示す関連情報を精度良く抽出することが可能な関連情報抽出プログラム、関連情報抽出方法及び関連情報抽出装置を提供することを目的とする。

本明細書に記載の関連情報抽出プログラムは、要件定義書から当該要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書から当該基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得し、取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成し、前記取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記生成した和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する、処理をコンピュータに実行させる関連情報抽出プログラムである。

本明細書に記載の関連情報抽出方法は、要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得する要素情報取得工程と、前記要素情報取得工程で取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する集合生成工程と、前記要素情報取得工程で取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記集合生成工程で生成した前記和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する関連情報抽出工程と、をコンピュータが実行する。

本明細書に記載の関連情報抽出装置は、要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得する要素情報取得手段と、前記要素情報取得手段が取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する集合生成手段と、前記要素情報取得手段が取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記集合生成手段が生成した前記和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する関連情報抽出手段と、を備える関連情報抽出装置である。

本明細書に記載の関連情報抽出プログラム、関連情報抽出方法及び関連情報抽出装置は、要件要素情報と設計要素情報との間の関連性を示す関連情報を精度良く抽出することができるという効果を奏する。

一実施形態に係るトレース情報抽出装置のハードウェア構成を示す図である。 図１のトレース情報抽出装置の機能ブロック図である。 要件定義書の一例を示す図である。 基本設計書の一例を示す図である。 要件要素情報ＤＢの一例を示す図である。 要件要素項目情報ＤＢの一例を示す図である。 設計要素情報ＤＢの一例を示す図である。 設計要素項目情報ＤＢの一例である。 トレース情報抽出処理（その１）を示すフローチャートである。 図９のステップＳ１６の処理（設計要素情報候補の抽出処理）を示すフローチャートである。 図１１（ａ）〜図１１（ｃ）は、図１０の処理を説明するための図である。 図９のステップＳ２０の処理（設計要素情報の項目情報の積集合の抽出処理）を示すフローチャートである。 図１３（a）、図１３（ｂ）は、図１２の処理を説明するための図である。 図９のステップＳ２４の処理（設計要素情報の項目情報の積集合の抽出処理）を示すフローチャートである。 積集合が空の場合の例について示す図である。 図１６（ａ）、図１６（ｂ）は、積集合が空集合の場合の、設計要素情報候補の設計要素群ＩＤの変更について説明するための図である。 図９のステップＳ２６の処理（設計項目和情報の生成・保存処理）を示すフローチャートである。 図１７の処理を説明するための図である。 図９のステップＳ２８の処理（要件要素項目情報の検索処理）を示すフローチャートである。 図１９の処理を説明するための図（その１）である。 図１９の処理を説明するための図（その２）である。 図１９の処理における検索結果（トレース候補情報ＤＢ）を示す図である。 トレース情報抽出処理（その２）を示す図である。 図２３のステップＳ４０（要件要素関連情報の抽出処理）を示すフローチャートである。 業務フローの一例を示す図である。 図２５の一部を拡大して示す図である 要件要素関連情報ＤＢを示す図である。 図２３のステップＳ４２（設計要素関連情報の抽出処理）を示すフローチャートである。 プロセス関連図の一例を示す図である。 設計要素関連情報ＤＢを示す図である。 トレース候補情報ＤＢを示す図である。 図２３のステップＳ４６（関連先要件要素情報の抽出処理）を示すフローチャートである。 図３３（ａ）、図３３（ｂ）は、図３２の処理を説明するための図である。 図２３のステップＳ５０の処理（関連先設計要素情報の抽出処理）を示すフローチャートである。 図３５（ａ）、図３５（ｂ）は、図３４の処理を説明するための図である。 図２３の処理の結果得られるトレース候補情報ＤＢを示す図である。 図３７（ａ）は、トレース情報抽出処理（その１）の処理の一部を模式的に示す図であり、図３７（ｂ）は、トレース情報抽出処理（その２）の処理の一部を模式的に示す図である。 設計要素群ＩＤ取得処理について示すフローチャートである。 図３９（ａ）は画面遷移図の一例であり、図３９（ｂ）は、図３９（ａ）の画面遷移図を用いた図３８の処理の結果得られる設計要素情報ＤＢを示す図である。 図３９（ａ）の画面遷移図から図３９（ｂ）の設計要素群ＩＤを取得する手順を模式的に示す図（その１）である。 図３９（ａ）の画面遷移図から図３９（ｂ）の設計要素群ＩＤを取得する手順を模式的に示す図（その２）である。 図３９（ａ）の画面遷移図から図３９（ｂ）の設計要素群ＩＤを取得する手順を模式的に示す図（その３）である。 図３８のステップＳ１０６（遷移情報から設計要素情報を生成する処理）を示すフローチャートである。 図４３の処理を説明するための図（その１）である。 図４５（ａ）〜図４５（ｆ）は、図４３の処理を説明するための図（その２）である。 変形例に係る処理を示すフローチャートである。 図４７（ａ）〜図４７（ｅ）は、図４６の処理を説明するための図（その１）である。 図４８（ａ），図４８（ｂ）は、図４６の処理を説明するための図（その２）である。

以下、関連情報抽出装置としてのトレース情報抽出装置の一実施形態について、図１〜図４５に基づいて詳細に説明する。なお、本実施形態のトレース情報抽出装置は、ソフトウェア開発において作成される要件定義書に変更が生じた場合に、その変更が基本設計書のどこに影響を与えるかを示す情報（トレース情報）を抽出する処理を実行する装置である。

図１には、トレース情報抽出装置１０のハードウェア構成が示されている。トレース情報抽出装置１０は、ＰＣ（Personal Computer）などの情報処理装置であり、図１に示すように、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、入力部９７、表示部９３、及び可搬型記憶媒体用ドライブ９９等を備えている。これらトレース情報抽出装置１０の構成各部は、バス９８に接続されている。トレース情報抽出装置１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（関連情報抽出プログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（関連情報抽出プログラム）をＣＰＵ９０が実行することにより、図２に示す各部の機能が実現されている。

図２は、トレース情報抽出装置１０の機能ブロック図である。図２に示すように、トレース情報抽出装置１０においては、ＣＰＵ９０により、要素情報取得手段としての要素情報取得部１２、遷移情報取得手段としての遷移情報取得部１４、集合生成手段としての設計要素候補判定部１８、関連情報抽出手段としてのトレース候補判定部１６、関連情報取得手段としての関連情報取得部２０、関連情報追加手段としての関連トレース候補抽出部２２、としての機能が実現されている。

なお、図２では、ＨＤＤ９６等に格納されている、要件要素情報ＤＢ３０、要件要素項目情報ＤＢ３２、設計要素情報ＤＢ３６、設計要素項目情報ＤＢ３４、設計項目積情報３７、設計項目和情報３９、トレース候補情報ＤＢ３８、要件要素関連情報ＤＢ４０、及び設計要素関連情報ＤＢ４２についても図示している。また、図２では、トレース情報抽出装置１０に対する入力（要件定義書５０及び基本設計書５２）についても図示している。図３には、要件定義書５０の一例が示され、図４には、基本設計書５２の一例が示されている。

要件定義書５０は、プログラム開発の現場において、オペレータ等が顧客の要求を業務要件やシステムの機能要件として定義したファイルである。要件定義書５０は、一例として、図３に示すように、画面一覧と画面レイアウトを含んでいる。画面一覧は、通し番号である「Ｎｏ.」に対して、「画面ＩＤ」、「画面名」、「概要」、「利用組織名／役割名」、「備考」の各項目が対応付けられている。また、画面レイアウトは、「画面ＩＤ」及び「画面名」に対応して、画面上における項目情報（区分、顧客コードなど）の配置等を定めている。

一方、基本設計書５２は、プログラム開発の現場において、オペレータ等がシステムの仕様や機能構成を定義したファイルである。基本設計書５２は、一例として、図４に示すように、画面一覧と画面項目定義とを含んでいる。画面一覧は、通し番号である「Ｎｏ.」に対して、「画面名」、画面識別子としての「画面ＩＤ」、「画面概要」、「利用組織」、「備考」の各項目が対応付けられている。また、画面項目定義は、画面ＩＤ及び画面名に対し、各画面項目の「画面項目名」、「画面項目英名」、「型」、「桁数」、…、「タブ順」、「備考」が対応付けられている。

次に、図２の機能ブロック図の各部及び各ＤＢについて詳細に説明する。

要素情報取得部１２は、要件定義書５０から、要件定義書５０が有する要件要素情報（要件要素ＩＤ（画面ＩＤ）や要件要素名（画面名））を取得して要件要素情報ＤＢ３０に保持（格納）するとともに、要件要素情報が有する要件要素項目名（区分、顧客コードなど）を取得して、要件要素項目情報ＤＢ３２に保持（格納）する。また、要素情報取得部１２は、基本設計書５２から、基本設計書５２が有する設計要素情報（設計要素ＩＤ（画面ＩＤ）や設計要素名（画面名））を取得して設計要素情報ＤＢ３６に保持（格納）するとともに、設計要素項目名（区分、顧客コードなど）を取得して、設計要素項目情報ＤＢ３４に保持（格納）する。

ここで、要件要素情報ＤＢ３０は、図５に示すような情報であり、通し番号「Ｎｏ．」に対し、「要件要素ＩＤ」、「要件要素名」の項目が対応付けられている。この図５の例では、要件要素情報ＤＢ３０は、画面に関する要件要素情報を格納しており、要件定義書に含まれる画面名（「空室検索」、「顧客管理」…）が抽出・定義されている。また、要件要素項目情報ＤＢ３２は、図６に示すような情報を格納するデータベースであり、通し番号「Ｎｏ．」に対し、「要件要素名」、「ファイル名」、「要件要素項目Ｎｏ．」、「要件要素項目名」の各項目が対応付けられている。図６の例では、例えば、画面「顧客管理」に関し、「区分」、「顧客コード」、「顧客」、「代表者名」、「カナ」、「郵便番号」、「住所」、「情報配信区分」、「顧客分類」、「利用支店」、「担当者」という画面項目が対応付けられている。

設計要素情報ＤＢ３６は、図７に示すような情報を格納するデータベースであり、通し番号「Ｎｏ．」に対し、遷移情報としての「設計要素群ＩＤ」、「設計要素ＩＤ」、「設計要素名」の各項目が対応付けられている。また、設計要素項目情報ＤＢ３４は、図８に示すような情報を格納するデータベースであり、通し番号「Ｎｏ．」に対し、「設計要素名」、「設計要素ＩＤ」、「ファイル名」、「設計要素項目Ｎｏ．」、「設計要素項目名」の各項目が対応付けられている。

図２に戻り、遷移情報取得部１４は、基本設計書５２の画面遷移図（図３９（ａ）参照）から、画面間の遷移情報を取得して、設計要素群ＩＤを決定・取得し、設計要素情報ＤＢ３６に格納する。

設計要素候補判定部１８は、トレース情報を設定する候補となる設計要素情報を、要素情報取得部１２で取得された設計要素情報ＤＢ３６から複数（例えば２つ）抽出する。そして、設計要素情報に対応する設計要素項目情報の積集合である設計項目積情報３７を生成し、積集合が空集合であるか否かを判定する。積集合が空であれば、設計要素候補判定部１８は、設計要素情報の候補からはずし、積集合が空でなければ、設計要素項目情報の和集合を生成し、設計項目和情報３９として保持する。

トレース候補判定部１６は、要素情報取得部１２が取得した要件要素項目情報と、設計要素候補判定部１８で保持した設計項目和情報３９とを比較する。そして、トレース候補判定部１６は、要件要素項目情報と設計項目和情報３９が同等となるような要件情報と設計情報を取得し、それらを組としてトレース候補情報ＤＢ３８に格納する。

関連情報取得部２０は、要件定義書５０が有する業務フローや基本設計書５２が有するプロセス関連図から、要件情報の関連情報と設計情報の関連情報を取得する。そして、関連情報取得部２０は、要件情報の関連情報を要件要素関連情報ＤＢ４０に保持（格納）するとともに、設計情報の関連情報を設計要素関連情報ＤＢ４２に保持（格納）する。

関連トレース候補抽出部２２は、トレース候補判定部１６がトレース候補情報ＤＢ３８に保持したトレース情報の組に含まれる要件要素情報の関連先の要件要素情報を抽出する。また、関連トレース候補抽出部２２は、トレース情報の組に含まれる設計要素情報の関連先の設計要素情報を、関連情報取得部２０で取得した設計要素関連情報ＤＢ４２から抽出する。そして、関連トレース候補抽出部２２は、抽出した要件要素情報と設計要素情報同士を、組としてトレース候補情報ＤＢ３８に保持する。

なお、トレース候補情報ＤＢ３８は、図２２、図３１、図３６に示すようなデータベースであり、要件要素関連情報ＤＢ４０は、図２７に示すようなデータベースである。また、設計要素関連情報ＤＢ４２は、図３０に示すようなデータベースである。これらのデータベースの詳細については、後述する。

（トレース情報抽出処理（その１））
次に、図９に沿って、その他図面を適宜参照しつつ、トレース情報抽出装置１０（要素情報取得部１２、設計要素候補判定部１８、トレース候補判定部１６）の処理（トレース情報抽出処理（その１））について詳細に説明する。なお、ここでは、画面に関する要件要素情報と設計要素情報間のトレース情報（関連情報）の抽出について説明する。

図９の処理では、まず、ステップＳ１０において、要素情報取得部１２が、要件要素情報及び要件要素項目情報の作成処理を行う。この場合、要素情報取得部１２は、読み込み対象となる要件定義書５０（例えば、図３）に含まれる画面に関する定義（画面一覧、画面レイアウト）を読み込む。そして、要素情報取得部１２は、要件情報（画面ＩＤや画面名）と、要件情報が有する項目情報（画面項目名（区分、顧客コード等））を取得して、要件要素情報ＤＢ３０（図５）、要件要素項目情報ＤＢ３２（図６）に格納する。

次いで、ステップＳ１２では、要素情報取得部１２が、設計要素情報及び設計要素項目情報の作成処理を行う。この場合、要素情報取得部１２は、読み込み対象となる基本設計書５２（例えば、図４）に含まれる画面に関する定義（画面一覧、画面項目定義）を読み込む。そして、要素情報取得部１２は、設計情報（画面ＩＤや画面名）と、設計情報を構成する項目情報（画面項目名）を取得して、設計要素情報ＤＢ３６（図７）、設計要素項目情報ＤＢ３４（図８）に格納する。

ここで、図７の設計要素情報ＤＢ３６では、各画面名（設計要素名）に群が設定されている。この場合、群の識別子である設計要素群ＩＤが“１”である設計要素として「物件検索」と「物件詳細照会」があり、設計要素群ＩＤが“２”である設計要素として「顧客情報管理」と「顧客情報登録」がある。なお、設計要素情報ＤＢ３６の設計要素群ＩＤは、所定の方法により決定されるものとする（当該所定の方法については、後述する（図３８等参照））。

一方、図８の設計要素項目情報ＤＢ３４には、画面「顧客情報管理」が、「区分」、「顧客コード」、「顧客」、「代表者名」、「カナ」、「郵便番号」、「住所」の画面項目を有すること、画面「顧客情報登録」が、「顧客コード」、「情報配信区分」、「顧客分類」、「利用支店」、「担当者」の画面項目を有すること、などが格納されている。

図９に戻り、次のステップＳ１４では、設計要素候補判定部１８が、未だ抽出が行われていない設計要素情報候補が残っているか否かを判断する。ここでは設計要素情報候補を１つも抽出していないので、判断は肯定され、ステップＳ１６に移行する。

次いで、ステップＳ１６では、設計要素候補判定部１８が、設計要素情報候補を抽出する処理を実行する。このステップＳ１６の処理では、設計要素候補判定部１８が、設計要素情報候補として、ステップＳ１２で取得した設計要素情報から設計要素群ＩＤが一致するものをまとまりとして抽出する。具体的には、設計要素候補判定部１８は、図１０のフローチャートに沿った処理を実行する。

図１０の処理では、まず、ステップＳ１６２において、設計要素候補判定部１８が、設計要素情報から設計要素を取り出し、設計要素情報候補とする。例えば、図１１（ａ）の設計要素情報の場合、破線で囲んだ設計要素が図１１（ｂ）のように取り出され、設計要素情報候補とされる。

次いで、ステップＳ１６４では、設計要素候補判定部１８が、設計要素情報候補の設計要素群ＩＤを抽出する。図１１（ｂ）の場合、設計要素群ＩＤ＝「１」が抽出される。

次いで、ステップＳ１６６では、設計要素候補判定部１８が、設計要素情報から次の設計要素を新たに取り出す。図１１（ａ）の設計要素情報の場合、図１１（ｃ）に示すように、Ｎｏ．＝２の設計要素が取り出される。

次いで、ステップＳ１６８では、設計要素候補判定部１８が、新たに取り出した設計要素の設計要素群ＩＤを抽出する。図１１（ｃ）の場合、設計要素群ＩＤ＝「１」が抽出される。

次いで、ステップＳ１７０では、設計要素候補判定部１８が、抽出した設計要素群ＩＤが一致するか否かを判断する。ここでの判断が肯定された場合（図１１（ｂ）、図１１（ｃ）では肯定される）、ステップＳ１７２に移行する。そして、ステップＳ１７２では、設計要素候補判定部１８が、新たに取り出した設計要素情報（図１１（ｃ））を設計要素情報候補とし、ステップＳ１６６以降の処理を実行する。

なお、ステップＳ１７０の判断が否定された場合、すなわち、抽出した設計要素群ＩＤが一致しなかった場合には、図１０の全処理が終了し、図９のステップＳ１８に移行する。

なお、図１０の全処理が終了した段階では、設計要素群ＩＤ＝１の設計要素情報が設計要素情報候補とされていたり、あるいは、設計要素群ＩＤ＝２の設計要素情報が設計要素情報候補とされていたりする。また、設計要素群ＩＤが一致する設計要素情報が３以上ある場合には、図１０の処理により、３つ以上の設計要素情報が抽出されることになる。なお、以下においては、説明の便宜上、設計要素群ＩＤ＝２の設計要素情報が設計要素情報候補とされている（図１３（ａ）参照）ものとする。

図９に戻り、ステップＳ１８では、設計要素候補判定部１８が、設計要素情報候補が複数あるか否かを判断する。例えば、図１３（ａ）の場合には、設計要素情報候補が２つあるので、ステップＳ１８の判断は肯定される。ステップＳ１８の判断が肯定されると、ステップＳ２０に移行する。一方、ステップＳ１６において設計要素情報候補が１つのみ抽出された場合には、ステップＳ１８の判断が否定され、ステップＳ２６に移行する。

ステップＳ２０に移行した場合、設計要素候補判定部１８は、設計要素情報の項目情報の積集合の抽出処理を行う。具体的には、図１２のフローチャートに沿った処理を実行する。

図１２の処理では、まず、ステップＳ２０２において、設計要素候補判定部１８が、設計要素情報候補を１つ取り出す。例えば図１３（ａ）の設計要素情報候補からは、「顧客情報管理」が取り出される。

次いで、ステップＳ２０４では、設計要素候補判定部１８が、取り出した設計要素情報候補に対応する設計要素項目情報を抽出する。この場合、例えば図１３（ｂ）のＮｏ．＝「３」の設計要素項目情報が抽出される。

次いで、ステップＳ２０６では、設計要素候補判定部１８が、設計要素情報候補はまだあるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２０２に戻る。そして、ステップＳ２０２では、設計要素候補判定部１８が、設計要素情報候補を新たに１つ取り出す。例えば図１３（ａ）の設計要素情報候補から、「顧客情報登録」が取り出される。次いで、ステップＳ２０４では、設計要素候補判定部１８が、新たに取り出した設計要素情報候補「顧客情報登録」に対応する設計要素項目情報を抽出する。この場合、例えば、図１３（ｂ）のＮｏ．＝「４」の設計要素項目情報が抽出される。

一方、ステップＳ２０６の判断が否定された場合には、ステップＳ２０８に移行する。ステップＳ２０８では、設計要素候補判定部１８が、対応する設計要素項目情報の設計要素項目名の積集合を抽出する。例えば、図１３（ｂ）の場合、抽出された設計要素項目情報で、共通する設計要素項目名は、「顧客コード」のみであるので、積集合として、「顧客コード」が抽出されることになる。

その後は、図１２の全処理を終了し、図９のステップＳ２２に移行する。ステップＳ２２では、設計要素候補判定部１８が、積集合が空であるか否かを判断する。ここでの判断が否定された場合には、ステップＳ２６に移行するが、肯定された場合には、ステップＳ２４に移行する。なお、図１３（ｂ）の場合は、ステップＳ２２の判断は否定される。

ここで、ステップＳ２２の判断が肯定される場合（積集合が空集合の場合）の例について説明する。ステップＳ２２の判断が肯定されてステップＳ２４に移行すると、設計要素候補判定部１８は、設計要素情報候補変更処理を実行する。具体的には、図１４のフローチャートに沿った処理が実行される。なお、ステップＳ２２の判断が肯定される場合の一例が、図１５に示されている。図１５では、設計要素群ＩＤが一致する４つの設計要素情報候補のすべてで、共通する設計要素項目名が存在していない。以下、図１５の例を用いて、図１４の処理を説明する。

図１４の処理では、まず、ステップＳ２４２において、設計要素候補判定部１８が、着目している設計要素情報候補から最後の１つを除く。図１５の例では、設計要素候補判定部１８は、設計要素情報候補から図１６（ａ）に矢印にて示すＮｏ．＝「４」の設計要素情報候補を除く。

次いで、ステップＳ２４４では、設計要素候補判定部１８が、最後の１つを除いた、残りの設計要素情報候補に対応する設計要素情報の設計要素群ＩＤを変更する。ここでは、例えば、図１６（ｂ）において実線矢印で示すように、設計要素群ＩＤを「１」から「１．１」に変更する。

次いで、ステップＳ２４６では、設計要素候補判定部１８が、除いた設計要素情報の設計要素群ＩＤを変更する。ここでは、例えば、図１６（ｂ）において破線矢印で示すように、設計要素群ＩＤを「１」から「１．２」に変更する。

次いで、ステップＳ２４８では、設計要素候補判定部１８が、設計要素群ＩＤが一致する設計要素情報を新たな設計要素情報候補とする。図１６（ｂ）の場合、設計要素群ＩＤ＝「１．１」の設計要素情報が新たな設計要素情報候補とされる。

その後は、図１４の全処理を終了し、ステップＳ１８に戻る。これ以降、ステップＳ１８〜Ｓ２２では、設計要素群ＩＤ＝「１．１」の設計要素情報についての処理が行われる。

その後、ステップＳ２２の判断が否定されるか、あるいは前述したステップＳ１８の判断が否定されると、ステップＳ２６に移行する。

ステップＳ２６では、設計要素候補判定部１８が、設計項目和情報の生成・保存処理を実行する。このステップＳ２６では、設計要素候補判定部１８は、図１７のフローチャートに沿った処理を実行する。

図１７の処理では、まず、ステップＳ２６２において、設計要素候補判定部１８が、設計要素項目情報を１つ取り出す。より詳細には、図１３（ｂ）で抽出された設計要素項目情報と同一の設計項目情報、すなわち、図１８に示す設計要素項目情報に含まれるＮｏ．＝「３」の設計要素項目情報（破線で囲んだ上側の設計要素項目情報）を抽出する。

次いで、ステップＳ２６４では、設計要素候補判定部１８が、設計要素項目情報はまだあるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２６２に戻る。そして、設計要素候補判定部１８は、ステップＳ２６２の処理を再度行う。具体的には、図１３（ｂ）で抽出された設計要素項目情報と同一の設計項目情報、すなわち、図１８に示す設計要素項目情報のＮｏ．＝「４」の設計要素項目情報（破線で囲んだ下側の設計要素項目情報）を抽出する。

次いで、ステップＳ２６４では、設計要素候補判定部１８が、設計要素項目情報はまだあるか否かを再度判断する。図１８の場合、図１３（ｂ）で抽出された設計要素項目情報と同一の設計項目情報は残っていないので、ステップＳ２６４の判断は肯定されることとなる。

次いで、ステップＳ２６６では、設計要素候補判定部１８が、図１８に示すように、取り出した設計要素項目情報の設計要素項目名の和集合を抽出し、設計項目和情報３９として保存する。図１８の場合、設計要素項目情報の和集合として、「区分」、「顧客コード」、「顧客」、「代表者名」、「カナ」、「郵便番号」、「住所」、「情報配信区分」、「顧客分類」、「利用支店」、「担当者」が抽出される。

上記のようにして、図１７の全処理が終了すると、図９のステップＳ２８に移行する。なお、設計要素項目情報が１つの場合（図９のステップＳ１８が否定されてステップＳ２６に移行した場合）には、当該設計要素項目情報そのものが和情報となる。

図９に戻り、次のステップＳ２８では、トレース候補判定部１６が、要件要素項目情報の検索処理を実行する。具体的には、トレース候補判定部１６は、図１９のフローチャートに沿った処理を実行する。

図１９の処理では、まず、ステップＳ２８２において、トレース候補判定部１６が、要件要素情報を１つ取り出す。ここでは、例えば、図２０の上段において実線で囲んで示すように、要件要素情報の中からＮｏ．＝「１」の要件要素情報が取り出される。

次いで、ステップＳ２８４では、トレース候補判定部１６が、要件要素情報に対応する要件要素項目情報を抽出する。図２０の例では、図２０の要件要素項目情報ＤＢ３２において実線で囲んで示すように、要件要素項目情報の中からＮｏ．＝「１」の要件要素項目情報が取り出される。

次いで、ステップＳ２８６では、トレース候補判定部１６が、ステップＳ２８４で抽出された要件要素項目情報の中から要件要素項目名を１つ取り出す。図２０では、要件要素項目情報の要件要素名「空室検索」から、要件要素項目名「受注日」が取り出される。

次いで、ステップＳ２８８では、トレース候補判定部１６が、要件要素項目が設計項目和情報に含まれるかをチェックする。そして、ステップＳ２９０では、トレース候補判定部１６が、含まれるか否かを判断する。ここでの判断が否定された場合（要件要素項目名「受注日」が抽出されている場合は否定される）、ステップＳ２９４に移行する。一方、ステップＳ２９０の判断が肯定された場合には、ステップＳ２９２に移行する。

ステップＳ２９２に移行すると、トレース候補判定部１６が、カウンタ（和集合に含まれた数をカウントするカウンタ）を１増やし、ステップＳ２９４に移行する。

そして、ステップＳ２９４では、トレース候補判定部１６が、要件要素項目名はまだあるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２８６に移行し、次の要件要素項目名（例えば、受注者）についてもステップＳ２８８〜Ｓ２９２の処理判断を行う。以降、全ての要件要素項目名についてステップＳ２８８〜Ｓ２９２を繰返し、ステップＳ２９４の判断が否定された段階で、ステップＳ２９６に移行する。

ステップＳ２９６に移行した場合、トレース候補判定部１６は、カウンタ／要件要素項目数が閾値以上であるか否かを判断する。すなわち、トレース候補判定部１６は、１つの要件要素項目情報における全要件要素項目名と、積集合が空集合でない複数の設計要素項目情報の和集合とを比較し、和集合に含まれている要件要素項目名の全要件要素項目名に対する割合が所定割合以上であるか否かを判断する。ここで、閾値は、適宜定めることができる値であるものとする。

ステップＳ２９６の判断が否定された場合には、ステップＳ３００に移行する。なお、図２０の要件要素項目情報Ｎｏ．＝「１」の要件要素項目情報については、ステップＳ２９６の判断が否定されるものとする。そして、ステップＳ３００に移行すると、トレース候補判定部１６は、要件要素情報がまだあるか（残っているか）否かを判断する。ここでの判断が肯定されると、ステップＳ２８２に戻り、次の要件要素情報（Ｎｏ．＝「２」の要件要素情報）について、上記と同様の処理を行う（図２１参照）。この場合、図２１に示すように、要件要素名「顧客管理」の要件要素項目名は全て設計要素項目情報の和集合に含まれているので、ステップＳ２９６の判断は肯定され、ステップＳ２９８に移行する。

ステップＳ２９８に移行すると、トレース候補判定部１６が、検索結果に、要件要素名「顧客管理」と、和集合を抽出した２つの設計要素名「顧客情報管理」及び「顧客情報登録」と、が関連しているという情報を追加する

以上のようにして、処理を行い、ステップＳ３００の判断が否定されると（要件要素情報がなくなると）、図１９の全処理を終了して、図９のステップＳ３０に移行する。

図９のステップＳ３０では、トレース候補判定部１６が、検索結果があるか否かを判断する。ここでの判断が否定された場合には、ステップＳ１４に戻るが、肯定された場合には、ステップＳ３２に移行する。

ステップＳ３２に移行した場合には、トレース候補判定部１６が、トレース候補情報として保持する。ここで、トレース候補情報ＤＢ３８には、図２２に示すように、設計要素ＩＤ、設計要素名、その設計要素が定義されている基本設計書のパスと、その設計要素に対応する要件要素ＩＤ、要件要素名、要件要素が定義されている要件定義書のパスとが、組として格納される。上述した図２０、図２１の例の場合、トレース候補判定部１６は、図２２に示すように、設計要素名「顧客情報管理」と要件要素名「顧客管理」とを組としてトレース候補情報ＤＢ３８に格納し、設計要素名「顧客情報登録」と要件要素名「顧客管理」とを組としてトレース候補情報ＤＢ３８に格納する。その後は、ステップＳ１４に戻る。

以降、ステップＳ１４の判断が否定されるまで上記処理を繰返し実行し、ステップＳ１４の判断が否定された段階で、図９のフローチャートの全処理が終了する。

以上の処理により、要件要素情報と、これに関連する設計要素情報との関連を示すトレース情報（関連情報）をトレース候補情報ＤＢ３８に格納することができる。

（トレース情報抽出処理（その２））
次に、図２３のフローチャートに沿って、その他図面を適宜参照しつつ、トレース情報抽出装置１０（関連情報取得部２０、関連トレース候補抽出部２２）の処理（トレース情報抽出処理（その２））について詳細に説明する。本処理は、要件定義書の業務フローと、基本設計書のプロセス関連図と、上記トレース情報抽出処理（その１）の結果得られたトレース候補情報ＤＢ３８とに基づいて、トレース候補情報を新たに抽出しトレース候補情報ＤＢ３８に追加する処理である。

図２３の処理では、まず、ステップＳ４０において、関連情報取得部２０が、要件要素関連情報の抽出処理を行う。このステップＳ４０では、関連情報取得部２０は、要件定義書５０の業務フロー（図２５参照）から、要件要素間の関連情報を抽出して、要件要素関連情報ＤＢ４０に保持する。なお、図２５の業務フローでは、機能を表す要件要素ごとに関連先の要件要素の情報が保持されている。ステップＳ４０では、具体的には、図２４のフローチャートに沿った処理が実行される。

図２４の処理では、まず、ステップＳ４０２において、関連情報取得部２０が、要件定義書５０から図２５に示す業務フローを読み込む。次いで、ステップＳ４０４では、関連情報取得部２０が、要件要素（機能）を１つ取り出す。ここでは、例えば、図２６において破線で囲んで示す「空室検索機能」が取り出されたものとする。

次いで、ステップＳ４０６では、関連情報取得部２０が、関連する要件要素があるか否かを判断する。ここでの判断が肯定されると、ステップＳ４０８に移行する。そして、ステップＳ４０８では、関連情報取得部２０が、関連する要件要素の種別・名前を取り出す。図２６では、「空室検索機能」に関連する要件要素の「種別・名前」として、一点鎖線で囲んで示す「画面・空室検索」、「概念データ・物件」が取り出される。

次いで、ステップＳ４１０では、関連情報取得部２０が、取り出した要件要素の種別・名前を、要件要素関連情報ＤＢ４０に保存する。具体的には、図２７に示すように、要件要素（機能）名「空室検索機能」に対して、「画面・空室検索」、「概念データ・物件」が関連付けられた状態で要件要素関連情報ＤＢ４０に保存される。なお、関連情報取得部２０は、矢印の向きに基づいて、入出力区分「ｉｎ」又は「ｏｕｔ」も要件要素関連情報ＤＢ４０に保存する。

次いで、ステップＳ４１２では、関連情報取得部２０が、取り出した要件要素（機能）の接続先の要件要素はあるか否かを判断する。ここでの判断が肯定されると、ステップＳ４０４に戻る。その後は、ステップＳ４０４において新たに要件要素（機能）を取り出し、上記と同様の処理・判断（Ｓ４０６〜Ｓ４１２）を実行する。なお、ステップＳ４０６の判断が否定された場合には、ステップＳ４０８、Ｓ４１０を経ずに、ステップＳ４１２に直接移行する。なお、図２６の例では、破線で囲んで示す要件要素（機能）が順次取り出され（Ｓ４０４）、図２７に示すように、３つの要件要素（機能）名に対して、関連する要件要素の種別・名前が保存される。

以上のようにして処理が行われ、ステップＳ４１２の判断が否定されると、図２４の全処理を終了し、図２３のステップＳ４２に移行する。

図２３に戻り、次のステップＳ４２では、関連情報取得部２０が、設計要素関連情報の抽出処理を実行する。このステップＳ４２では、関連情報取得部２０が、基本設計書５２のプロセス関連図（図２９参照）から、設計要素の関連情報を抽出して、設計要素関連情報ＤＢ４２に保持（格納）する。なお、図２９のプロセス関連図では、機能を表す設計要素ごとに関連先の設計要素の情報が保持されている。ステップＳ４２では、具体的には、図２８のフローチャートに沿った処理が実行される。

図２８の処理では、まず、ステップＳ４２２において、関連情報取得部２０が、プロセス関連図（図２９）を読み込む。次いで、ステップＳ４２４では、関連情報取得部２０が、設計要素（機能）を１つ取り出す。ここでは、例えば、図２９において、破線で囲んで示す設計要素（機能）「顧客登録」が取り出されたものとする。

次いで、ステップＳ４２６では、関連情報取得部２０が、関連する設計要素があるか否かを判断する。図２９の場合、設計要素（機能）「顧客登録」に関連する設計要素として、一点鎖線で囲んで示す設計要素「顧客情報登録」があるので、ステップＳ４２６の判断は肯定され、ステップＳ４２８に移行する。

ステップＳ４２８に移行すると、関連情報取得部２０は、関連する設計要素の「種別・名前」を取り出す。図２９の場合、関連する設計要素の「種別・名前」として、「画面・顧客情報登録」が取り出される。

次いで、ステップＳ４３０では、関連情報取得部２０が、ステップＳ４２８において取り出した関連する設計要素の「種別・名前」を設計要素関連情報ＤＢ４２に保存する。具体的には、図３０に示すように、設計要素（機能）名「顧客登録」に関連付けて、「画面・顧客情報登録」が設計要素関連情報ＤＢ４２に保存される。なお、関連情報取得部２０は、矢印の向きに基づいて、入出力区分「ｉｎ」又は「ｏｕｔ」も設計要素関連情報ＤＢ４２に保存する。

次いで、ステップＳ４３２では、関連情報取得部２０が、設計要素（機能）はほかにあるか否かを判断する。ここでの判断が肯定されると、ステップＳ４２４に戻る。その後は、ステップＳ４２４において新たに設計要素（機能）を取り出し、上記と同様の処理・判断（Ｓ４２６〜Ｓ４３２）を実行する。なお、ステップＳ４２６の判断が否定された場合には、ステップＳ４２８、Ｓ４３０を経ずに、ステップＳ４３２に直接移行する。

以上のようにして処理が行われ、ステップＳ４３２の判断が否定されると、図２８の全処理を終了し、図２３のステップＳ４４に移行する。なお、図２８の全処理が終了した段階では、設計要素関連情報ＤＢ４２が、図３０に示す状態になっているものとする。

次いで、ステップＳ４４では、関連トレース候補抽出部２２が、トレース候補情報を１つ取り出す。具体的には、関連トレース候補抽出部２２は、上述したトレース情報抽出処理（その１）で生成されたトレース候補情報（図２２参照）の中から、例えば、図３１において破線で囲んで示すトレース候補情報を１つ取り出す。

次いで、ステップＳ４６では、関連トレース候補抽出部２２が、関連先要件要素情報の抽出処理を実行する。このステップＳ４６では、関連トレース候補抽出部２２は、図３２のフローチャートに沿った処理を実行する。

図３２の処理では、まず、ステップＳ４６２において、関連トレース候補抽出部２２が、ステップＳ４４で取り出したトレース候補情報から、要件要素情報を抽出する。具体的には、関連トレース候補抽出部２２は、図３３（ａ）において実線で囲んで示す要件要素情報を抽出する。

次いで、ステップＳ４６４では、関連トレース候補抽出部２２が、要件要素関連情報を１つ取り出す。具体的には、関連トレース候補抽出部２２は、要件要素関連情報ＤＢ４０（図２７参照）の中から、例えば、図３３（ｂ）において破線で囲んで示す要件要素関連情報を抽出する。

次いで、ステップＳ４６６では、関連トレース候補抽出部２２が、ステップＳ４６２において抽出した要件要素名と等しいものが、ステップＳ４６４で取り出した要件要素関連情報にあるか否かを判断する。図３３（ｂ）の破線で囲んで示す要件要素関連情報の場合、図３３（ａ）において実線で囲んだ要件要素名と等しくないので、ここでの判断は否定される。この場合、ステップＳ４７０に移行する。ステップＳ４７０では、関連トレース候補抽出部２２が、要件要素関連情報がまだあるか否かを判断する。ここでの判断が肯定されると、ステップＳ４６４に戻る。

その後は、図３３（ｂ）の要件要素関連情報「顧客管理機能」及び「進捗登録機能」についても、上記と同様の処理を行う。ここで、ステップＳ４６４において、要件要素関連情報「顧客管理機能」が取り出された場合には、その中に要件要素名「顧客管理」を含んでいる。この場合、要件要素名「顧客管理」は、図３３（ａ）において実線で囲んで示す要件要素名「顧客管理」と等しい。したがって、ステップＳ４６６の判断は肯定されることになる。

ステップＳ４６６の判断が肯定されると、ステップＳ４６８に移行し、関連トレース候補抽出部２２は、現時点で取り出されている要件要素関連情報「顧客管理機能」を関連先要件要素情報として保持する。

以上の処理を行い、ステップＳ４７０の判断が否定されると、図３２の全処理が終了し、図２３のステップＳ４８に移行する。

ステップＳ４８に移行すると、関連トレース候補抽出部２２は、関連先要件要素情報があるか否かを判断する。ここでの判断が肯定されると、ステップＳ５０に移行する。なお、ステップＳ４８の判断が否定された場合、すなわち、ステップＳ４６において、関連先要件要素情報が保持されなかった場合には、ステップＳ５６に移行する。

ステップＳ４８が肯定され、ステップＳ５０に移行すると、関連トレース候補抽出部２２は、関連先設計要素情報の抽出処理を実行する。具体的には、関連トレース候補抽出部２２は、図３４のフローチャートに沿った処理を実行する。

図３４の処理では、まず、ステップＳ５０２において、関連トレース候補抽出部２２が、トレース候補情報から設計要素情報を抽出する。具体的には、関連トレース候補抽出部２２は、図３５（ａ）において実線で囲んで示す設計要素情報を抽出する。

次いで、ステップＳ５０４では、関連トレース候補抽出部２２が、設計要素関連情報を１つ取り出す。具体的には、関連トレース候補抽出部２２は、設計要素関連情報ＤＢ４２（図３０参照）の中から、例えば、図３５（ｂ）において破線で囲んで示す設計要素関連情報を抽出する。

次いで、ステップＳ５０６では、関連トレース候補抽出部２２が、ステップＳ５０２において抽出した設計要素名と等しいものが、ステップＳ５０４において取り出した設計要素関連情報にあるか否かを判断する。図３５（ｂ）の破線で囲んで示す設計要素関連情報の場合、図３５（ａ）において実線で囲んだ設計要素名と等しくないので、ここでの判断は否定される。この場合、ステップＳ５１０に移行する。ステップＳ５１０では、関連トレース候補抽出部２２が、設計要素関連情報がまだあるか否かを判断する。ここでの判断が肯定されると、ステップＳ５０４に戻る。

その後は、図３５（ｂ）の設計要素関連情報「顧客管理」についても、上記と同様の処理を行う。ここで、ステップＳ５０４において、設計要素関連情報「顧客管理」が取り出された場合には、その中に設計要素名「顧客情報管理」を含んでいる。この場合、設計要素名「顧客情報管理」は、図３５（ａ）において実線で囲んで示す設計要素名「顧客情報管理」と等しい。したがって、ステップＳ５０６の判断は肯定されることになる。

ステップＳ５０６の判断が肯定されると、ステップＳ５０８に移行し、関連トレース候補抽出部２２は、現時点で取り出されている設計要素関連情報「顧客管理」を関連先設計要素情報として保持する。

その後は、上記と同様の処理を行い、ステップＳ５１０の判断が否定された段階で図３４の全処理を終了し、図２３のステップＳ５２に移行する。

図２３のステップＳ５２に移行すると、関連トレース候補抽出部２２は、関連先設計要素情報があるか否かを判断する。ここでの判断が肯定されると、ステップＳ５４に移行する。なお、ステップＳ５２の判断が否定された場合には、ステップＳ５６に移行する。

ステップＳ５４に移行した場合、すなわち、関連先要件要素情報及び関連先設計要素情報の両方が関連トレース候補抽出部２２において保持されている場合には、関連トレース候補抽出部２２が、それらの情報をトレース候補情報ＤＢ３８に保持する。具体的には、図３６の矢印Ａで示すように、トレース候補情報ＤＢ３８に対して、関連先要件要素情報「顧客管理機能」と、関連先設計要素情報「顧客管理」を格納する。

次いで、ステップＳ５６では、関連トレース候補抽出部２２が、トレース候補情報がまだあるか否かを判断する。この場合、図３１に示すように、トレース候補情報がまだ残っている（Ｎｏ．＝２）ので、ここでの判断は肯定され、ステップＳ４４に戻る。なお、その後は、新たなトレース候補情報について、上記と同様の処理（ステップＳ４４〜Ｓ５６）を実行する。なお、トレース候補情報（Ｎｏ．＝２）に関する処理（ステップＳ４４〜Ｓ５６）が終了した段階では、図３６の矢印Ｂで示すトレース候補情報が、トレース候補情報ＤＢ３８に格納される。その後、ステップＳ５６の判断が否定された段階で、図２３の全処理を終了する。

以上のように、図２３のトレース情報抽出処理（その２）が行われることで、トレース情報抽出処理（その１）で抽出されたトレース候補情報（図３７（ａ））を利用して、図３７（ｂ）に示す新たなトレース候補情報をトレース候補情報ＤＢ３８に追加できたことになる。

（設計要素群ＩＤの決定方法）
次に、図７に示す設計要素情報ＤＢ３６に含まれている設計要素群ＩＤの取得方法について、図３８のフローチャートに沿って説明する。この図３８の処理は、図２の遷移情報取得部１４が実行する処理である。なお、以下においては、説明の簡単のため、図３９（ａ）に示す画面遷移図に基づいて、図３９（ｂ）に示す設計要素群ＩＤを取得する場合を例に採り説明する。なお、図４０〜図４２は、図３９（ａ）の画面遷移図から図３９（ｂ）の設計要素群ＩＤを取得する手順を模式的に示す図である。また、説明を簡便化するため、図３９（ｂ）、図４５（ｆ）にある「設計要素ＩＤ」については記述を省略する。

図３８の処理では、まず、ステップＳ７０において、遷移情報取得部１４が、画面遷移図を読み込む。ここでは、図３９（ａ）に示す画面遷移図が読み込まれたものとする。

次いで、ステップＳ７２では、遷移情報取得部１４が、始点（スタート）の接続先を取り出し、出現画面・遷移元画面として保存する。図３９（ａ）の場合、図４０の（１）に示すように、出現画面及び遷移画面として「画面Ａ」が取り出される。また、遷移情報取得部１４は、始点からの深さカウンタを１とし、遷移情報として、始点からの深さ、始点、終点（遷移元画面に相当）を保存する。

次いで、ステップＳ７４では、遷移情報取得部１４が、遷移先の画面を抽出し、遷移元画面候補として保存する。図３９（ａ）の場合、遷移先の画面として「画面Ｂ」、「画面Ｄ」が抽出され、図４０の（２）に示すように遷移元画面候補として保存される。また、遷移情報取得部１４は、始点からの深さカウンタを１増やす（始点からの深さ＝２）。

次いで、ステップＳ７６では、遷移情報取得部１４が、遷移元画面候補から１つ取り出して、遷移元画面候補から消去する。具体的には、図４０の（３）に示すように、「画面Ｂ」と「画面Ｄ」のいずれか（図４９の（３）では「画面Ｂ」）を遷移元画面候補から取り出し、消去する。

次いで、ステップＳ７８では、遷移情報取得部１４が、取り出した遷移元画面候補（「画面Ｂ」）を、出現画面に保存する。また、遷移情報取得部１４は、遷移情報を保存する。この状態が、図４０の（４）に示されている。遷移情報には、始点からの深さ＝２と、始点「画面Ａ」、終点「画面Ｂ」が保存される。

次いで、ステップＳ８０では、遷移情報取得部１４が、ステップＳ７８で出現画面に保存した画面を、遷移元画面に追加する。また、遷移情報取得部１４は、ステップＳ７６で取り出した画面の遷移先の画面を抽出し、遷移元画面候補として追加する。また、遷移情報取得部１４は、始点からの深さカウンタを１増やす。すなわち、遷移情報取得部１４は、図４０の（５）に示すように、遷移元画面に「画面Ｂ」を追加し、遷移元画面候補に画面Ｂの遷移先である「画面Ｃ」を追加し、始点からの深さのカウンタを「３」にする。

次いで、ステップＳ８２では、遷移情報取得部１４が、抽出した遷移先画面から１つ取り出し、遷移元画面候補から消す。図４０の（６）では、「画面Ｃ」が遷移元画面候補から取り出され、消去されている。

次いで、ステップＳ８４では、遷移情報取得部１４が、取り出した遷移先画面が空であるか否かを判断する。図４０の場合、画面Ｃが取り出されているので、ここでの判断は否定され、ステップＳ８６に移行する。そして、ステップＳ８６に移行すると、遷移情報取得部１４が、取り出した遷移先画面が「エンド」か否かを判断する。ここでは、取り出した遷移先画面はエンドではないので、判断は否定され、ステップＳ８８に移行する。

ステップＳ８８に移行すると、遷移情報取得部１４は、取り出した遷移先画面（画面Ｃ）は出現画面に含まれているか否かを判断する。ここでは、出現画面には画面Ａ，Ｂしか含まれていないので、判断は否定され、ステップＳ９０に移行する。

ステップＳ９０では、遷移情報取得部１４が、取り出した画面（画面Ｃ）を出現画面として保存し、遷移情報を保存する。より具体的には、遷移情報取得部１４は、図４０の（７）に示すように、出現画面を「画面Ａ」、「画面Ｂ」、「画面Ｃ」とし、遷移情報に始点の深さ＝３と、始点「画面Ｂ」、終点「画面Ｃ」を保存する。その後は、ステップＳ８０に戻る。

ステップＳ８０では、図４１の（８）に示すように、遷移情報取得部１４が、ステップＳ９０で出現画面に保存した画面（画面Ｃ）を、遷移元画面に追加する。また、遷移情報取得部１４は、ステップＳ８２で取り出した画面の遷移先の画面（エンド）を抽出し、遷移元画面候補として追加する。また、遷移情報取得部１４は、始点からの深さカウンタを１増やし、「４」とする。

次いで、ステップＳ８２では、遷移情報取得部１４が、抽出した遷移先画面から１つ（ここでは、「エンド」）を取り出し、遷移元画面候補から消す。図４１の（９）では、「エンド」が遷移元画面候補から取り出され、消去されている。

次いで、ステップＳ８４では、遷移情報取得部１４が、取り出した遷移先画面が空であるか否かを判断する。ここでは、「エンド」が取り出されているので、ここでの判断は否定され、ステップＳ８６に移行する。そして、ステップＳ８６に移行すると、遷移情報取得部１４が、取り出した遷移先画面がエンドか否かを判断する。ここでは、取り出した遷移先画面がエンドであるので、判断は肯定されステップＳ９４に移行する。

ステップＳ９４に移行すると、遷移情報取得部１４は、図４１の（１０）に示すように、遷移情報を保存する。ここでは、始点からの深さ＝４と、始点「画面Ｃ」、終点「エンド」を保存する。

次いで、ステップＳ９６では、遷移情報取得部１４が、遷移元画面候補はまだあるか否かを判断する。ここでは、遷移元画面候補に画面Ｄが残っているので、判断が肯定され、ステップＳ９８に移行する。

ステップＳ９８では、遷移情報取得部１４が、遷移元画面候補から１つ（ここでは「null」）を取り出す。次いで、ステップＳ１００では、遷移情報取得部１４が、取り出した遷移元画面候補がnull（空）であるか否かを判断する。ここでの判断が肯定されると、ステップＳ１０２に移行する。

ステップＳ１０２では、遷移情報取得部１４が、始点からの深さカウンタを１減らすとともに、遷移元画面を減らす。この場合、図４１の（１１）に示すように、始点からの深さが３になり、遷移元画面が「画面Ａ」、「画面Ｂ」となる。その後は、ステップＳ９６に戻る。

ステップＳ９６に戻ると、遷移情報取得部１４が、遷移元画面候補はまだあるか否かを判断する。ここでは、遷移元画面候補に画面Ｄが残っているので、判断が肯定され、ステップＳ９８に移行する。

ステップＳ９８では、遷移情報取得部１４が、遷移元画面候補から１つ（ここでは「null」）を取り出す。次いで、ステップＳ１００では、遷移情報取得部１４が、取り出した遷移元画面候補がnull（空）であるか否かを判断する。ここでの判断が肯定されると、ステップＳ１０２に移行する。

ステップＳ１０２では、遷移情報取得部１４が、始点からの深さカウンタを１減らすとともに、遷移元画面を減らす。この場合、図４１の（１２）に示すように、始点からの深さが２になり、遷移元画面が「画面Ａ」となる。その後は、ステップＳ９６に戻る。

ステップＳ９６に戻ると、遷移情報取得部１４が、遷移元画面候補はまだあるか否かを判断する。ここでは、遷移元画面候補に画面Ｄが残っているので、判断が肯定され、ステップＳ９８に移行する。

ステップＳ９８では、遷移情報取得部１４が、遷移元画面候補から１つ（ここでは「画面Ｄ」）を取り出す（図４１の（１３））。次いで、ステップＳ１００では、遷移情報取得部１４が、取り出した遷移元画面候補がnull（空）であるか否かを判断する。ここでの判断が否定されると、ステップＳ１０４に移行し、遷移情報取得部１４は、遷移元画面候補から「画面Ｄ」を消す。その後は、ステップＳ７８に戻る。

ステップＳ７８では、遷移情報取得部１４が、取り出した遷移元画面候補（「画面Ｄ」）を、出現画面に保存する。また、遷移情報取得部１４は、遷移情報を保存する。この状態が、図４２の（１５）に示されている。遷移情報には、始点からの深さ＝２と、始点「画面Ａ」、終点「画面Ｄ」が保存される。

次いで、ステップＳ８０では、遷移情報取得部１４が、ステップＳ７８で出現画面に保存した画面（画面Ｄ）を、遷移元画面に追加する。また、遷移情報取得部１４は、取り出した画面（画面Ｄ）の遷移先の画面（画面Ｃ）を抽出し、遷移元画面候補として追加し、始点からの深さカウンタを１増やす（図４２の（１６）参照）。

次いで、ステップＳ８２では、遷移情報取得部１４が、抽出した遷移先画面から１つ（画面Ｃ）取り出し、遷移元画面候補から消す（図４２の（１７）参照）

次いで、ステップＳ８４では、遷移情報取得部１４が、取り出した遷移先画面が空であるか否かを判断する。ここでの判断が否定されるとステップＳ８６に移行し、ステップＳ８６の判断も否定されると、ステップＳ８８に移行する。

そして、ステップＳ８８に移行すると、遷移情報取得部１４は、取り出した遷移先画面（画面Ｃ）は出現画面に含まれているか否かを判断する。ここでは、出現画面には画面Ｃが含まれているので、判断が肯定され、ステップＳ９２に移行する。

ステップＳ９２に移行すると、遷移情報取得部１４が、遷移情報を保存する。具体的には、遷移情報取得部１４は、図４２の（１８）に示すように、始点からの深さ＝３と、始点「画面Ｄ」、終点「画面Ｃ」を保存する。その後は、ステップＳ８２に戻る。

ステップＳ８２に戻ると、遷移情報取得部１４は、抽出した遷移先画面から１つ（ここでは、null）を取り出し、遷移元画面候補から消す（図４２の（１９）参照）。

次いで、ステップＳ８４では、遷移情報取得部１４が、取り出した遷移先画面が空であるか否かを判断する。ここでの判断が肯定されると、ステップＳ９６に移行し、遷移情報取得部１４が、遷移元画面候補はまだあるか否かを判断する。ここでは、遷移元画面候補にnullが残っているので、判断が肯定され、ステップＳ９８に移行する。そして、ステップＳ９８では、遷移情報取得部１４が、遷移元画面候補から１つ（ここでは「null」）を取り出す。次いで、ステップＳ１００では、遷移情報取得部１４が、取り出した遷移元画面候補がnullであるか否かを判断する。ここでの判断が肯定されると、ステップＳ１０２に移行し、遷移情報取得部１４が、始点からの深さカウンタを１減らすとともに、遷移元画面を減らす（図４２の（２０）参照）。

その後はステップＳ９６に戻るが、遷移元画面候補はまだあるので、判断は肯定され、ステップＳ９８において、遷移情報取得部１４が、遷移元画面候補から１つ（null）を取り出す。この場合、次のステップＳ１００の判断が肯定されるので、ステップＳ１０２において、始点からの深さを１減らすとともに、遷移元画面を減らす（図４２の（２１）参照）。

その後ステップＳ９６に戻ると、この段階では遷移元画面候補が全てなくなっているので、ステップＳ９６の判断は否定され、ステップＳ１０６に移行する。

ステップＳ１０６に移行した場合、遷移情報取得部１４は、遷移情報（図４２の（１８）参照）から設計要素情報を生成する処理を実行する。このステップＳ１０６の処理では、図４３のフローチャートに沿った処理が実行される。

図４３の処理では、まず、ステップＳ１１０において、遷移情報取得部１４が、遷移情報を１行読み込む。ここでは、例えば、図４４の遷移情報の１行目が読み込まれたものとする。

次いで、ステップＳ１１２では、遷移情報取得部１４が、最終行か否かを判断する。ここでの判断が否定されると、ステップＳ１１４に移行し、遷移情報取得部１４が、始点からの深さをキーに、始点と終点の組を遷移組情報に格納する。具体的には、図４４の（２２）に示すように、地点からの深さ＝１に対応して、｛スタート，Ａ｝が格納される。

その後は、遷移情報取得部１４は、ステップＳ１１０と、ステップＳ１１２（否定）と、ステップＳ１１４とを繰り返す。これにより、図４４の（２３）〜（２７）に示すように、遷移組情報には、始点からの深さをキーとして始点と終点の組が格納される。そして、全ての行の処理が終了し、ステップＳ１１２の判断が肯定されると、ステップＳ１１６に移行する。

ステップＳ１１６に移行すると、遷移情報取得部１４が、深さ１の遷移の組の終点を取り出す。ここでは、図４５（ａ）の始点からの深さ１に対応する遷移の組の終点である「画面Ａ」が取り出される。

次いで、ステップＳ１１８では、遷移情報取得部１４が、深さ２の遷移の組を１つ取り出す。ここでは、図４５（ａ）の始点からの深さ２の遷移の組の１つである、｛Ａ，Ｂ｝が取り出されたものとする。

次いで、ステップＳ１２０では、遷移情報取得部１４が、経路候補情報に、取り出した深さ２の遷移の組の始点・終点を順に格納する。この場合の経路候補情報の状態が、図４５（ｂ）に示されている。

次いで、ステップＳ１２２では、遷移情報取得部１４が、経路候補数をカウントする。次いで、ステップＳ１２４では、遷移情報取得部１４が、経路候補数のカウント値に基づいて、遷移の組がまだあるか否かを判断する。ここでの判断が肯定されると、ステップＳ１１８に戻り、遷移情報取得部１４が、深さ２の遷移の組を１つ取り出す。ここでは、図４５（ａ）の始点からの深さ２の遷移の組の１つである、｛Ａ，Ｄ｝が取り出されたものとする。

次いで、ステップＳ１２０では、遷移情報取得部１４が、経路候補情報に、取り出した深さ２の遷移の組の始点・終点を順に格納する。この場合の経路候補情報の状態が、図４５（ｃ）に示されている。その後、ステップＳ１２２の経路候補数カウント処理を経て、ステップＳ１２４の判断が否定されると、ステップＳ１２６に移行する。

ステップＳ１２６に移行すると、遷移情報取得部１４は、１つ深い遷移（ここでは深さ３）に着目する。次いで、ステップＳ１２８では、遷移情報取得部１４が、最も深いか、すなわち、深さ３は図４５（ａ）の最大深さであるか否かを判断する。ここでの判断が否定されると、ステップＳ１３０に移行する。

ステップＳ１３０に移行すると、遷移情報取得部１４は、遷移の組を取り出す。ここでは、図４５（ａ）に示す、深さ３に対応する遷移の組の１つである｛Ｂ，Ｃ｝が取り出されたものとする。

次いで、ステップＳ１３２では、遷移情報取得部１４が、経路候補を１つ取り出す。ここでは、図４５（ｃ）のＮｏ．＝１の経路候補Ａ，Ｂが取り出されたものとする。

次いで、ステップＳ１３４では、遷移情報取得部１４が、経路候補の終点（ここではＢ）と遷移の組の始点（ここではＢ）が一致するか否かを判断する。ここでの判断が肯定されると、ステップＳ１３６に移行する。

ステップＳ１３６に移行すると、遷移情報取得部１４は、遷移の組の終点（ここではＣ）を経路候補として追加格納する。このときの経路候補情報の状態が、図４５（ｄ）に示されている。

次いで、ステップＳ１３８では、遷移情報取得部１４が、経路候補はまだあるか否かを判断する。ここでの判断が肯定されると、ステップＳ１３２に戻る。

ステップＳ１３２に戻ると、経路候補Ａ，Ｄと、遷移の組Ｂ，Ｃとを用いた処理になるが、この場合には、ステップＳ１３４の判断が否定されるので、ステップＳ１３８に移行する。そして、ステップＳ１３８では、経路候補が残っていないため、判断が否定されて、ステップＳ１４０に移行する。ステップＳ１４０では、遷移情報取得部１４が、遷移の組はまだあるか否かを判断する。ここでは、まだ、遷移の組として｛Ｄ，Ｃ｝が残っているので、判断が肯定されステップＳ１３０に戻る。

ステップＳ１３０に戻ると、遷移情報取得部１４は、遷移の組を取り出す。ここでは、図４５（ａ）に示す、深さ３に対応する遷移の組の１つである｛Ｄ，Ｃ｝が取り出されたものとする。次いで、ステップＳ１３２では、遷移情報取得部１４が、経路候補を１つ取り出す。ここでは、図４５（ｃ）のＮｏ．＝１の経路候補Ａ，Ｂが取り出されたものとする。

次いで、ステップＳ１３４では、遷移情報取得部１４が、経路候補の終点（ここではＢ）と遷移の組の始点（ここではＤ）が一致するか否かを判断する。ここでの判断が否定されると、ステップＳ１３８に移行する。ステップＳ１３８では、経路候補がまだ残っているので、判断が肯定されて、ステップＳ１３２に戻る。

ステップＳ１３２では、遷移情報取得部１４が、図４５（ｃ）のＮｏ．＝２の経路候補Ａ，Ｄが取り出す。そして、ステップＳ１３４の判断が肯定されると、ステップＳ１３６において、遷移情報取得部１４が、遷移の組の終点（ここではＤ）を経路候補として追加格納する。このときの経路候補情報の状態が、図４５（ｅ）に示されている。その後は、ステップＳ１３８、Ｓ１４０の判断がともに否定されるので、ステップＳ１２６に戻る。

ステップＳ１２６に戻ると、遷移情報取得部１４は、１つ深い遷移（ここでは深さ４）に着目する。次いで、ステップＳ１２８では、遷移情報取得部１４が、最も深いか、すなわち、深さ４は図４５（ａ）の最大深さであるか否かを判断する。ここでの判断が肯定されると、ステップＳ１４２に移行する。

ステップＳ１４２に移行すると、遷移情報取得部１４は、経路候補情報を設計要素情報のフォーマットに変換する。具体的には、図４５（ｆ）に示すようなフォーマットに変換する。この場合、経路候補情報の「Ｎｏ．」が、設計要素情報ＤＢ３６における「設計要素群ＩＤ」に変換されている。以上の処理が終了すると、図４３の全処理及び図３８の全処理が終了する。

以上のように、画面遷移図に基づいて、設計要素群ＩＤを取得することにより、遷移関係がある画面が、同一の設計要素群として定義されることになる。これにより、上述したトレース情報抽出処理（その１）及びトレース情報抽出処理（その２）を高精度に行うことが可能となる。

以上、詳細に説明したように、本実施形態によると、要素情報取得部１２が、要件定義書５０に含まれる複数の要件要素情報と要件要素項目情報を取得するとともに、基本設計書５２に含まれる複数の設計要素情報と設計要素項目情報を取得し、設計要素候補判定部１８が、取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する。そして、トレース候補判定部１６は、要素情報取得部１２が取得した要件要素情報の１つを抽出し、その要件要素情報が有する要件要素項目情報と和集合とを比較して、要件要素項目情報が和集合に所定割合以上（閾値以上）含まれていた場合に、要件要素項目情報に対応する要件要素情報と和集合に対応する複数の設計要素情報との組をトレース情報として抽出する。このように、関連のある（積集合が空集合でない）複数の設計要素項目情報の和集合と要件要素項目情報とを比較することで、要件定義書５０での１つの要件要素情報が基本設計書５２で複数の設計要素情報に分かれるような場合であっても、高精度にトレース情報を抽出することができる。この場合、従来技術のように、要件要素の名称の類似性を利用するような場合と比較しても、トレース情報の抽出を精度良く行うことが可能となる。

また、本実施形態によると、関連情報取得部２０が、要件定義書５０に含まれる業務フロー（図２５）から、各要件要素情報に関連する情報を要件要素関連情報として取得するとともに、基本設計書５２に含まれるプロセス関連図（図２９）から、各設計要素情報に関連する情報を設計要素関連情報として取得する。そして、関連トレース候補抽出部２２が、トレース候補判定部１６で抽出されたトレース情報に含まれる組の１つを取得し、関連情報取得部２０が取得した要件要素関連情報の中から組に含まれる要件要素情報の関連先の要件要素情報を抽出するとともに、関連情報取得部２０が取得した設計要素関連情報の中から組に含まれる設計要素情報の関連先の設計要素情報を抽出し、トレース情報として追加する。このように、業務フローやプロセス関連図に更に基づいてトレース情報を追加することで、より高精度なトレース情報の抽出が可能となる。これにより、結果として、トレース情報抽出の網羅性が高められ、網羅性検証や影響分析を効率化することが可能となる。

また、本実施形態によると、遷移情報取得部１４が、基本設計書の画面遷移図の画面間の遷移情報に基づいて、複数の設計要素情報間の遷移関係を示す遷移情報（設計要素群ＩＤ）を取得する。これにより、本実施形態では、実際の画面遷移図に基づいて、精度良く遷移情報（設計要素群ＩＤ）を取得することが可能となる。

（変形例）
なお、上記実施形態では、画面遷移図（図３９（ａ））に基づいて、設計要素情報ＤＢ３６の設計要素群ＩＤを取得・設定する場合について説明したが、これに限られるものではない。例えば、基本設計書５２の画面一覧に含まれる画面ＩＤに基づいて、設計要素群ＩＤを取得することも可能である。

以下、画面ＩＤに基づいて設計要素群ＩＤを取得する方法について、図４６のフローチャートに沿って、その他図面を適宜参照しつつ、詳細に説明する。

図４６の処理では、まず、ステップＳ１７０において、遷移情報取得部１４が、画面一覧（図４７（ａ））から設計要素を１つ取り出し、画面ＩＤを抽出し、設計要素群ＩＤ候補として保持する。ここでは、設計要素群ＩＤ候補として、「HB_JH_BP004_SCR011」が保持されたものとする（図４７（ｃ）のように、設計要素群ＩＤ候補とした「HB_JH_BP004_SCR011」の「設計要素群ＩＤ候補」に「TRUE」フラグをたてる）。

次いで、ステップＳ１７２では、遷移情報取得部１４が、抽出した画面ＩＤの末尾の数値部分を除いた文字列を抽出し、分割値として保持する。この場合、図４７（ｂ）の（３０）に示すように、太線枠で囲んだ部分「HB_JH_BP004_SCR」が分割値として保持されることになる。

次いで、ステップＳ１７４では、遷移情報取得部１４が、画面一覧から設計要素を１つ取り出し、画面ＩＤを抽出する。ここでは、画面ＩＤとして、「HB_JH_BP004_SCR012」が抽出されたものとする。

次いで、ステップＳ１７６では、遷移情報取得部１４が、抽出した画面ＩＤの末尾の数値部分とそれ以外の文字列に分割する。この場合、画面ＩＤ「HB_JH_BP004_SCR012」が、「012」と「HB_JH_BP004_SCR」に分割される（図４７（ｂ）の（３１）参照）。

次いで、ステップＳ１７８では、遷移情報取得部１４は、抽出した数値以外の文字列「HB_JH_BP004_SCR」が、ステップＳ１７２で保持した分割値と一致するか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１８０に移行する。

ステップＳ１８０に移行した場合、遷移情報取得部１４は、抽出した設計要素ＩＤ（HB_JH_BP004_SCR012）を設計要素群ＩＤ候補として保持する（図４７（ｄ）の「設計要素群ID候補」の値が「TRUE」になる）。

次いで、ステップＳ１８２では、遷移情報取得部１４が、画面一覧に設計要素はまだあるか否かを判断する。ここでの判断が肯定されると、ステップＳ１７４に戻る。

ステップＳ１７４に戻ると、遷移情報取得部１４は、画面一覧から設計要素を１つ取り出し、画面ＩＤを抽出する。ここでは、画面ＩＤとして、「HB_JH_BP005_SCR001」が抽出されたものとする。

次いで、ステップＳ１７６では、遷移情報取得部１４が、抽出した画面ＩＤの末尾の数値部分とそれ以外の文字列に分割する。この場合、画面ＩＤ「HB_JH_BP005_SCR001」が、「001」と「HB_JH_BP005_SCR」に分割される。

次いで、ステップＳ１７８では、遷移情報取得部１４が、抽出した数値以外の文字列「HB_JH_BP005_SCR」が、ステップＳ１７２の分割値と一致するか否かを判断する。ここでの判断が否定されると、ステップＳ１８４に移行する。

ステップＳ１８４に移行すると、遷移情報取得部１４は、設計要素群ＩＤ候補として保持している画面ＩＤに対して、設計要素群ＩＤ（ここでは、１）を与える。また、遷移情報取得部１４は、設計要素群ＩＤ候補（TRUE）をクリアし、抽出した設計要素ＩＤを候補として保持する（「TRUE」を設定する。図４７（ｅ）参照）。

次いで、ステップＳ１８６では、遷移情報取得部１４が、抽出した数値以外の文字列「HB_JH_BP005_SCR」を分割値として保持する。その後は、ステップＳ１８２に移行する。

ステップＳ１８２に移行すると、遷移情報取得部１４が、画面一覧に設計要素はまだあるか否かを判断する。ここでの判断が肯定されると、ステップＳ１７４に戻る。その後は、ステップＳ１７４において、画面ＩＤ「HB_JH_BP005_SCR002」が抽出され、ステップＳ１７６において、画面ＩＤ「HB_JH_BP005_SCR002」が、「002」と「HB_JH_BP005_SCR」に分割される。そして、ステップＳ１７８の判断が肯定される。更に、ステップＳ１８０において、画面ＩＤ「HB_JH_BP005_SCR002」が設計要素群ＩＤ候補として保持され（図４８（ａ）参照）、ステップＳ１８２の判断が否定され、ステップＳ１８８に移行する。

ステップＳ１８８に移行すると、遷移情報取得部１４は、設計要素群ＩＤ候補として保持した画面ＩＤに対して、設計要素群ＩＤを与える。具体的には、図４８（ｂ）に示すように、画面ＩＤ「HB_JH_BP005_SCR001」、「HB_JH_BP005_SCR002」に対して、設計要素群ＩＤ＝２を与える。以上の処理が終了すると、図４６の全処理が終了する。

以上のような処理を行うことで、画面ＩＤに基づいて、設計要素群ＩＤを取得することができる。これにより、上記実施形態と同様、上述したトレース情報抽出処理（その１）及び（その２）を高精度に行うことが可能となる。

なお、上記実施形態及び変形例では、画面に関する要件要素情報と設計要素情報間のトレース情報の抽出を例に採り説明したが、これに限られるものではない。例えば、機能、概念データ、帳票、インタフェースなどに関する要件要素情報と設計要素情報間のトレース情報を抽出する場合にも本発明は好適に適用できる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１） 要件定義書から当該要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書から当該基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得し、
取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成し、
前記取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記生成した和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する、処理をコンピュータに実行させる関連情報抽出プログラム。
（付記２） 前記要件定義書に含まれる業務フローから、各要件要素情報に関連する情報を要件要素関連情報として取得するとともに、前記基本設計書に含まれるプロセス関連図から、各設計要素情報に関連する情報を設計要素関連情報として取得し、
前記抽出された関連情報に含まれる組の１つを取得し、前記取得した要件要素関連情報の中から前記組に含まれる要件要素情報の関連先の要件要素情報を抽出するとともに、前記取得した設計要素関連情報の中から前記組に含まれる設計要素情報の関連先の設計要素情報を抽出し、前記関連先の要件要素情報と前記関連先の設計要素情報との組を前記関連情報に追加する、処理を前記コンピュータに更に実行させることを特徴とする付記１に記載の関連情報抽出プログラム。
（付記３） 複数の前記設計要素情報間の遷移関係を示す遷移情報を取得する処理を前記コンピュータに更に実行させることを特徴とする付記１又は２に記載の関連情報抽出プログラム。
（付記４） 前記遷移情報を取得する処理では、前記基本設計書の画面遷移図の画面間の遷移情報に基づいて、あるいは前記基本設計書の画面に対して付与された画面識別子に基づいて、前記遷移情報を取得することを特徴とする付記３に記載の関連情報抽出プログラム。
（付記５） 要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得する要素情報取得工程と、
前記要素情報取得工程で取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する集合生成工程と、
前記要素情報取得工程で取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記集合生成工程で生成した前記和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する関連情報抽出工程と、をコンピュータが実行することを特徴とする関連情報抽出方法。
（付記６） 前記要件定義書に含まれる業務フローから、各要件要素情報に関連する情報を要件要素関連情報として取得するとともに、前記基本設計書に含まれるプロセス関連図から、各設計要素情報に関連する情報を設計要素関連情報として取得する関連情報取得工程と、
前記関連情報抽出工程で抽出した前記関連情報に含まれる組の１つを取得し、前記関連情報取得工程で取得した要件要素関連情報の中から前記組に含まれる要件要素情報の関連先の要件要素情報を抽出するとともに、前記関連情報取得工程で取得した設計要素関連情報の中から前記組に含まれる設計要素情報の関連先の設計要素情報を抽出し、前記関連先の要件要素情報と前記関連先の設計要素情報との組を前記関連情報に追加する関連情報追加工程と、を前記コンピュータが更に実行することを特徴とする付記５に記載の関連情報抽出方法。
（付記７） 複数の前記設計要素情報間の遷移関係を示す遷移情報を取得する遷移情報取得工程を前記コンピュータが更に実行することを特徴とする付記５又は６に記載の関連情報抽出方法。
（付記８） 前記遷移情報取得工程では、前記基本設計書の画面遷移図の画面間の遷移情報に基づいて、あるいは前記基本設計書の画面に対して付与された画面識別子に基づいて、前記遷移情報を取得することを特徴とする付記７に記載の関連情報抽出方法。
（付記９） 要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得する要素情報取得手段と、
前記要素情報取得手段が取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する集合生成手段と、
前記要素情報取得手段が取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記集合生成手段が生成した前記和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する関連情報抽出手段と、を備える関連情報抽出装置。
（付記１０） 前記要件定義書に含まれる業務フローから、各要件要素情報に関連する情報を要件要素関連情報として取得するとともに、前記基本設計書に含まれるプロセス関連図から、各設計要素情報に関連する情報を設計要素関連情報として取得する関連情報取得手段）と、
前記関連情報抽出手段で抽出された前記関連情報に含まれる組の１つを取得し、前記関連情報取得手段が取得した要件要素関連情報の中から前記組に含まれる要件要素情報の関連先の要件要素情報を抽出するとともに、前記関連情報取得手段が取得した設計要素関連情報の中から前記組に含まれる設計要素情報の関連先の設計要素情報を抽出し、前記関連先の要件要素情報と前記関連先の設計要素情報との組を前記関連情報に追加する関連情報追加手段と、を更に備える付記９に記載の関連情報抽出装置。
（付記１１） 複数の前記設計要素情報間の遷移関係を示す遷移情報を取得する遷移情報取得手段を更に備える付記９又は１０に記載の関連情報抽出装置。
（付記１２） 前記遷移情報取得手段は、前記基本設計書の画面遷移図の画面間の遷移情報に基づいて、あるいは前記基本設計書の画面に対して付与された画面識別子に基づいて、前記遷移情報を取得することを特徴とする付記１１に記載の関連情報抽出装置。

１０ トレース情報抽出装置（関連情報抽出装置）
１２ 要素情報取得部（要素情報取得手段）
１４ 遷移情報取得部（遷移情報取得手段）
１６ トレース候補判定部（関連情報抽出手段）
１８ 設計要素候補判定部（集合生成手段）
２０ 関連情報取得部（関連情報取得手段）
２２ 関連トレース候補抽出部（関連情報追加手段）

Claims (6)

1. 要件定義書から当該要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書から当該基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得し、
   取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成し、
   前記取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記生成した和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する、
   処理をコンピュータに実行させる関連情報抽出プログラム。
2. 前記要件定義書に含まれる業務フローから、各要件要素情報に関連する情報を要件要素関連情報として取得するとともに、前記基本設計書に含まれるプロセス関連図から、各設計要素情報に関連する情報を設計要素関連情報として取得し、
   前記抽出された関連情報に含まれる組の１つを取得し、前記取得した要件要素関連情報の中から前記組に含まれる要件要素情報の関連先の要件要素情報を抽出するとともに、前記取得した設計要素関連情報の中から前記組に含まれる設計要素情報の関連先の設計要素情報を抽出し、前記関連先の要件要素情報と前記関連先の設計要素情報との組を前記関連情報に追加する、
   処理を前記コンピュータに更に実行させることを特徴とする請求項１に記載の関連情報抽出プログラム。
3. 複数の前記設計要素情報間の遷移関係を示す遷移情報を取得する処理を前記コンピュータに更に実行させることを特徴とする請求項１又は２に記載の関連情報抽出プログラム。
4. 前記遷移情報を取得する処理では、前記基本設計書の画面遷移図の画面間の遷移情報に基づいて、あるいは前記基本設計書の画面に対して付与された画面識別子に基づいて、前記遷移情報を取得することを特徴とする請求項３に記載の関連情報抽出プログラム。
5. 要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得する要素情報取得工程と、
   前記要素情報取得工程で取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する集合生成工程と、
   前記要素情報取得工程で取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記集合生成工程で生成した前記和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する関連情報抽出工程と、
   をコンピュータが実行することを特徴とする関連情報抽出方法。
6. 要件定義書に含まれる複数の要件要素情報と当該要件要素情報が有する項目情報である要件要素項目情報を取得するとともに、基本設計書に含まれる複数の設計要素情報と当該設計要素情報が有する項目情報である設計要素項目情報を取得する要素情報取得手段と、
   前記要素情報取得手段が取得した複数の設計要素情報のうち、該設計要素情報が有する前記設計要素項目情報の積集合が空集合でない設計要素情報の組み合わせを抽出するとともに、抽出した設計要素項目情報の和集合を生成する集合生成手段と、
   前記要素情報取得手段が取得した要件要素情報の１つを抽出し、当該抽出した要件要素情報が有する要件要素項目情報と前記集合生成手段が生成した前記和集合とを比較して、当該要件要素項目情報が前記和集合に所定割合以上含まれていた場合に、当該要件要素項目情報に対応する要件要素情報と前記和集合に対応する設計要素情報との組を、前記要件要素情報と前記設計要素情報との間の関連性を示す関連情報として抽出する関連情報抽出手段と、
   を備える関連情報抽出装置。

Images