(57)【要約】【課題】各フィーチャに対応する全ての仕様要素を容易に管理し得ると共に、不要な仕様要素が含まれない仕様書を容易に生成する。【解決手段】  実施形態の仕様書出力可否判定手段は、前記出力可否判定ルールに基づいて、前記仕様データ記憶手段内の仕様データに含まれる出力可否情報のＮＵＬＬ値を出力可又は出力否の値に更新することを判定し、この判定結果に従って当該更新を実行する。実施形態の仕様書生成手段は、前記仕様書出力可否判定手段による更新が完了すると、前記仕様データ記憶手段内の仕様データのうち、出力可の値の出力可否情報に関連付けられた全ての仕様要素を抽出し、当該抽出した全ての仕様要素における仕様要素のＩＤ、属性、及び関連仕様要素ＩＤが記述された前記仕様書データを生成する。【選択図】図１
2012053567.tif 000002
【特許請求の範囲】
【請求項１】
仕様データ記憶手段及び出力可否判定ルール記憶手段を備えた仕様書生成装置に用いられる仕様書生成プログラムであって、
前記仕様書生成装置を、
特定のアプリケーションの仕様書データに記述すべき仕様要素毎に、他の仕様要素から参照される参照先の仕様要素のＩＤ、及び属性を互いに関連付けた参照先の仕様データと、この参照先の仕様要素を参照する参照元の仕様要素のＩＤ、属性、及び前記参照先の仕様要素のＩＤを示す関連仕様要素ＩＤを互いに関連付けた参照元の仕様データとをそれぞれ読み込む手段、
前記読み込んだ各仕様データのうち、前記参照先の仕様データに対し、ＮＵＬＬ値の選択状態、及びＮＵＬＬ値の出力可否情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照先の仕様データを前記仕様データ記憶手段に書き込む手段、
前記読み込んだ各仕様データのうち、前記参照元の仕様データに対し、前記特定のアプリケーションの仕様要素として選択か未選択かを示してＮＵＬＬ値の初期値をもつ選択状態、前記仕様書として出力可か出力否かを示してＮＵＬＬ値の初期値をもつ出力可否情報、及び前記関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照元の仕様データを前記仕様データ記憶手段に書き込む手段、
前記特定のアプリケーションのフィーチャモデルにおけるフィーチャに対応する仕様要素のＩＤを示す関連仕様要素ＩＤ、及び当該フィーチャを選択するか否かを示すフィーチャ選択フラグを互いに関連付けた仕様要素選択状態データを読み込む手段、
前記読み込んだ仕様要素選択状態データに対し、前記フィーチャＩＤ毎に、当該フィーチャＩＤに関連付けられた関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された仕様要素選択状態データを保持する手段、
前記保持した仕様要素選択状態データ内の関連仕様要素ＩＤ及びフィーチャ選択フラグに基づき、この関連仕様要素ＩＤに一致する前記仕様データ記憶手段内の仕様データの仕様要素のＩＤに関し、この仕様要素のＩＤに関連付けられた選択状態のＮＵＬＬ値を当該フィーチャ選択フラグに従って選択又は未選択を示す値に更新する手段、
前記仕様データ記憶手段内の仕様データのうち、ＮＵＬＬ値の出力可否情報に関連付けられた判定対象の仕様要素に関し、前記仕様データ記憶手段記憶手段内の仕様データ、及び前記保持した仕様要素選択状態データに基づく、各々の前記仕様要素の出力可否を判定するルールである出力可否判定ルールを前記出力可否判定ルール記憶手段に書き込む手段、
前記出力可否判定ルールに基づいて、前記仕様データ記憶手段内の仕様データに含まれる出力可否情報のＮＵＬＬ値を出力可又は出力否の値に更新することを判定し、この判定結果に従って当該更新を実行する仕様書出力可否判定手段、
前記仕様書出力可否判定手段による更新が完了すると、前記仕様データ記憶手段内の仕様データのうち、出力可の値の出力可否情報に関連付けられた全ての仕様要素を抽出し、当該抽出した全ての仕様要素における仕様要素のＩＤ、属性、及び関連仕様要素ＩＤが記述された前記仕様書データを生成する仕様書生成手段、
として機能させるための仕様書生成プログラム。
【請求項２】
請求項１に記載の仕様書生成プログラムにおいて、
前記仕様書生成装置を、
外部から読み込んだ前記出力可否判定ルールを前記出力可否判定ルール記憶手段に書き込む出力可否判定ルール読込み手段、
として更に機能させるための仕様書生成プログラム。
【請求項３】
請求項１又は請求項２に記載の仕様書生成プログラムにおいて、
前記仕様書生成装置を、
前記仕様書出力可否判定手段による更新が完了すると、前記仕様書生成手段による仕様書データの生成よりも先行して、前記仕様書出力可否判定手段による更新結果を出力することにより、当該更新結果の修正内容と修正命令、又は前記仕様書生成手段の起動命令の入力を促す手段、
前記更新結果の修正内容と修正命令の入力を受け付けると、当該修正内容と修正命令に基づいて前記更新結果を修正する手段、
前記起動命令の入力を受け付けると、前記仕様書生成手段を起動する手段、
として更に機能させるための仕様書生成プログラム。
【請求項４】
仕様データ記憶手段を備えた仕様書生成装置であって、
特定のアプリケーションの仕様書データに記述すべき仕様要素毎に、他の仕様要素から参照される参照先の仕様要素のＩＤ、及び属性を互いに関連付けた参照先の仕様データと、この参照先の仕様要素を参照する参照元の仕様要素のＩＤ、属性、及び前記参照先の仕様要素のＩＤを示す関連仕様要素ＩＤを互いに関連付けた参照元の仕様データとをそれぞれ読み込む手段と、
前記読み込んだ各仕様データのうち、前記参照先の仕様データに対し、ＮＵＬＬ値の選択状態、及びＮＵＬＬ値の出力可否情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照先の仕様データを前記仕様データ記憶手段に書き込む手段と、
前記読み込んだ各仕様データのうち、前記参照元の仕様データに対し、前記特定のアプリケーションの仕様要素として選択か未選択かを示してＮＵＬＬ値の初期値をもつ選択状態、前記仕様書として出力可か出力否かを示してＮＵＬＬ値の初期値をもつ出力可否情報、及び前記関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照元の仕様データを前記仕様データ記憶手段に書き込む手段と、
前記特定のアプリケーションのフィーチャモデルにおけるフィーチャに対応する仕様要素のＩＤを示す関連仕様要素ＩＤ、及び当該フィーチャの選択又は未選択を示すフィーチャ選択フラグを互いに関連付けた仕様要素選択状態データを読み込む手段と、
前記読み込んだ仕様要素選択状態データに対し、前記フィーチャＩＤ毎に、当該フィーチャＩＤに関連付けられた関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された仕様要素選択状態データを保持する手段と、
前記保持した仕様要素選択状態データ内の関連仕様要素ＩＤ及びフィーチャ選択フラグに基づき、この関連仕様要素ＩＤに一致する前記仕様データ記憶手段内の仕様データの仕様要素のＩＤに関し、この仕様要素のＩＤに関連付けられた選択状態のＮＵＬＬ値を当該フィーチャ選択フラグに従って選択又は未選択を示す値に更新する手段と、
前記仕様データ記憶手段内の仕様データのうち、ＮＵＬＬ値の出力可否情報に関連付けられた判定対象の仕様要素に関し、前記仕様データ記憶手段内の仕様データ、及び前記保持した仕様要素選択状態データに基づく、各々の前記仕様要素の出力可否を判定するためのルールである出力可否判定ルールを記憶する出力可否判定ルール記憶手段と、
前記出力可否判定ルールに基づいて、前記仕様データ記憶手段内の仕様データに含まれる出力可否情報のＮＵＬＬ値を出力可又は出力否の値に更新することを判定し、この判定結果に従って当該更新を実行する仕様書出力可否判定手段と、
前記仕様書出力可否判定手段による更新が完了すると、前記仕様データ記憶手段内の仕様データのうち、出力可の値の出力可否情報に関連付けられた全ての仕様要素を抽出し、当該抽出した全ての仕様要素における仕様要素のＩＤ、属性、及び関連仕様要素ＩＤが記述された前記仕様書データを生成する仕様書生成手段と、
を備えたことを特徴とする仕様書生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、仕様書生成プログラム及び装置に関する。
【背景技術】
【０００２】
ソフトウェア開発においては、生産性の向上、品質の安定、及びリードタイムの短縮を図る観点から、品質の保証されたソフトウェア部品を蓄積して再利用することが有効である。再利用の対象は、プログラム、コンポーネント、フレームワーク等へと変化している。このような変化の中、同一ドメインの製品開発に限定するものの、様々な種類の成果物を体系的に再利用の対象とすることにより、再利用の有効性を向上させるプロダクトライン型のソフトウェア開発手法が注目されている。
【０００３】
プロダクトライン型のソフトウェア開発手法では、製品開発のロードマップを描き、対象製品を開発するためのコアアセットと呼ばれるソフトウェア開発の資産をあらかじめ整備し、これらのコアアセットを利用して製品を開発する。コアアセットとしては、アーキテクチャ、ソフトウェアコンポーネント、ドメインモデル、要求説明書、文書と仕様書、性能モデル、テストケース、プロセス説明書等のように、ソフトウェア開発のプロセスで作成又は利用するためのあらゆる成果物が含まれる。
【０００４】
プロダクトライン型ソフトウェア開発のプロセスは、ドメイン開発プロセスと、アプリケーション開発プロセスにより構成される。
【０００５】
ドメイン開発プロセスにおいては、アプリケーション群の共通性と、特定のアプリケーションに対応する可変性とを備えるコアアセットを開発する。この共通性と可変性は、一般的には、システムのフィーチャ（特性）の集合を階層的に構造化したツリーからなるフィーチャモデルで表現される。ここで、フィーチャは、システムの特性を意味している。フィーチャモデルでは、それぞれのフィーチャを更に他のフィーチャに分解可能である。また、フィーチャモデルでは、フィーチャを選択する際の制約として、それぞれのフィーチャに対する必須、選択可能、又は選択制限対象といった属性や、他のフィーチャとの依存関係を定義可能となっている。
【０００６】
アプリケーション開発プロセスにおいては、ドメイン開発プロセスで開発したコアアセットを再利用して、特定のアプリケーションを開発する。このアプリケーション開発プロセスでは、フィーチャモデルで定義された制約に従い、コアアセットに含まれるフィーチャのうちアプリケーションで使用するフィーチャを選択して、コアアセットの可変性を固定する。
【０００７】
アプリケーション開発プロセスにおいてコアアセットを再利用するためには、フィーチャモデルの各フィーチャと、コアアセットとの対応関係を管理する必要がある。
【０００８】
しかしながら、仕様書においては、アプリケーション群の共通性と、特定のアプリケーションに対応する可変性とを混在して記述することが一般的である。そのため、仕様書をコアアセットとして再利用する場合、フィーチャと仕様書とを単に対応付けるだけでは不十分であり、仕様書を構成する仕様要素をフィーチャと対応付けて管理する必要がある。
【０００９】
この管理により、アプリケーション開発プロセスでは、選択したフィーチャに対応付けられた仕様要素から構成される仕様書を作成可能としている。このような仕様書作成技術としては、仕様書をＸＭＬで記述することにより、文章で記述された仕様における可変性を表現している方法が知られている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００７−１２００３号公報
【特許文献２】特開２００９−２２３８５６号公報
【非特許文献】
【００１１】
【非特許文献１】Ｋ・ポール他，ソフトウェアプロダクトラインエンジニアリング−ソフトウェア製品系列開発の基礎と概念から技法まで−，株式会社エスアイビー・アクセス，２００９。
【非特許文献２】I. John, D. Muthig, Modeling variability with use cases, Technical Report IESE Report No. 063.02/E, Fraunhofer IESE, 2002.
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、以上のような仕様書作成技術では、通常は特に問題ないが、本発明者の検討によれば、フィーチャと仕様要素との対応関係を管理する場合に、以下の２つの不都合がある。
【００１３】
第１の不都合の前提として、開発対象のソフトウェアの規模が大きくなるに従い、仕様書に記載する内容が多くなり、フィーチャと対応付ける仕様要素も増加することが挙げられる。仕様書に記載すべき内容は、フィーチャモデルとは異なる視点で構成されるため、フィーチャと仕様要素との対応関係が複雑になることが多い。例えば、あるフィーチャに対応する「機能」に関する仕様要素が、「画面」に関する仕様要素と「帳票」に関する仕様要素とを参照している場合、そのフィーチャは「機能」の仕様要素の他に、「画面」の仕様要素及び「帳票」の仕様要素にも対応していることになる。
【００１４】
従って、前述した方法でフィーチャと仕様要素との対応関係を管理する場合、ドメイン開発者においては、各フィーチャに対応する全ての仕様要素を特定することが困難であるという第１の不都合がある。
【００１５】
第２の不都合の前提として、選択（固定）したフィーチャに対応する仕様要素により構成される仕様書を、仕様要素間の関連を考慮せずに生成した場合、本来記載すべきではない仕様要素が仕様書に含まれてしまうことが挙げられる。例えば、ある「機能」と「画面」の仕様要素が関連していて、その「機能」の仕様要素には、選択されていないあるフィーチャが対応しており、その「画面」の仕様要素には、選択された別のフィーチャが対応している場合を考える。この場合、仕様要素間の関連を考慮せずに、「選択されたフィーチャに対応する仕様要素を、仕様書として出力する」というルールに従い仕様書を生成した場合、アプリケーションの機能として必要のない「画面」の仕様要素が仕様書として出力されてしまう。
【００１６】
従って、前述した方法でフィーチャと仕様要素との対応関係を管理する場合、仕様要素間の関連までは管理できないため、不要な仕様要素が仕様書に含まれてしまうという第２の不都合がある。その結果、仕様書の品質が低下し、その仕様書に従って開発したアプリケーションに仕様不備が混入してしまう可能性が生じてしまう。
【００１７】
本明細書に開示した実施形態は、各フィーチャに対応する全ての仕様要素を容易に管理し得ると共に、不要な仕様要素が含まれない仕様書を容易に生成し得る仕様書生成プログラム及び装置を提供することを目的とする。
【課題を解決するための手段】
【００１８】
以下で説明する実施形態の仕様書生成装置は、仕様データ記憶手段を備えている。
【００１９】
実施形態の仕様書生成装置は、特定のアプリケーションの仕様書データに記述すべき仕様要素毎に、他の仕様要素から参照される参照先の仕様要素のＩＤ、及び属性を互いに関連付けた参照先の仕様データと、この参照先の仕様要素を参照する参照元の仕様要素のＩＤ、属性、及び前記参照先の仕様要素のＩＤを示す関連仕様要素ＩＤを互いに関連付けた参照元の仕様データとをそれぞれ読み込む。
【００２０】
実施形態の仕様書生成装置は、前記読み込んだ各仕様データのうち、前記参照先の仕様データに対し、ＮＵＬＬ値の選択状態、及びＮＵＬＬ値の出力可否情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照先の仕様データを前記仕様データ記憶手段に書き込む。
【００２１】
実施形態の仕様書生成装置は、前記読み込んだ各仕様データのうち、前記参照元の仕様データに対し、前記特定のアプリケーションの仕様要素として選択か未選択かを示してＮＵＬＬ値の初期値をもつ選択状態、前記仕様書として出力可か出力否かを示してＮＵＬＬ値の初期値をもつ出力可否情報、及び前記関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照元の仕様データを前記仕様データ記憶手段に書き込む。
【００２２】
実施形態の仕様書生成装置は、前記特定のアプリケーションのフィーチャモデルにおけるフィーチャに対応する仕様要素のＩＤを示す関連仕様要素ＩＤ、及び当該フィーチャの選択又は未選択を示すフィーチャ選択フラグを互いに関連付けた仕様要素選択状態データを読み込む。
【００２３】
実施形態の仕様書生成装置は、前記読み込んだ仕様要素選択状態データに対し、前記フィーチャＩＤ毎に、当該フィーチャＩＤに関連付けられた関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された仕様要素選択状態データを保持する。
【００２４】
実施形態の仕様書生成装置は、前記保持した仕様要素選択状態データ内の関連仕様要素ＩＤ及びフィーチャ選択フラグに基づき、この関連仕様要素ＩＤに一致する前記仕様データ記憶手段内の仕様データの仕様要素のＩＤに関し、この仕様要素のＩＤに関連付けられた選択状態のＮＵＬＬ値を当該フィーチャ選択フラグに従って選択又は未選択を示す値に更新する。
【００２５】
また、実施形態の仕様書生成装置は、出力可否判定ルール記憶手段、仕様書出力可否判定手段及び仕様書生成手段を備えている。
【００２６】
出力可否判定ルール記憶手段は、前記仕様データ記憶手段内の仕様データのうち、ＮＵＬＬ値の出力可否情報に関連付けられた判定対象の仕様要素に関し、前記仕様データ記憶手段内の仕様データ、及び前記保持した仕様要素選択状態データに基づく、各々の前記仕様要素の出力可否を判定するためのルールである出力可否判定ルールを記憶する。
【００２７】
仕様書出力可否判定手段は、前記出力可否判定ルールに基づいて、前記仕様データ記憶手段内の仕様データに含まれる出力可否情報のＮＵＬＬ値を出力可又は出力否の値に更新することを判定し、この判定結果に従って当該更新を実行する。
【００２８】
仕様書生成手段は、前記仕様書出力可否判定手段による更新が完了すると、前記仕様データ記憶手段内の仕様データのうち、出力可の値の出力可否情報に関連付けられた全ての仕様要素を抽出し、当該抽出した全ての仕様要素における仕様要素のＩＤ、属性、及び関連仕様要素ＩＤが記述された前記仕様書データを生成する。
【図面の簡単な説明】
【００２９】
【図１】第１の実施形態に係る仕様書生成装置の構成を示す模式図である。
【図２】同実施形態における仕様メタ情報の一例を説明するための模式図である。
【図３】同実施形態における仕様データの一例を説明するための模式図である。
【図４】同実施形態におけるフィーチャモデルの一例を説明するための模式図である。
【図５】同実施形態における仕様要素選択状態データの一例を説明するための模式図である。
【図６】同実施形態における変換後の仕様データの一例を説明するための模式図である。
【図７】同実施形態における変換後の仕様要素選択状態データの一例を説明するための模式図である。
【図８】同実施形態における動作を説明するためのフローチャートである。
【図９】同実施形態における選択状態の更新後の仕様データの一例を説明するための模式図である。
【図１０】同実施形態におけるステップＳＴ３０の動作を説明するためのフローチャートである。
【図１１】同実施形態における判定サブルーチンの動作を説明するためのフローチャートである。
【図１２】同実施形態における出力可否の更新後の仕様データの一例を説明するための模式図である。
【図１３】第２の実施形態に係る仕様書生成装置の構成を示す模式図である。
【図１４】同実施形態における変換した仕様データの構造の一例を表現したクラス図である。
【図１５】同実施形態における出力可否判定ルールの一例を示す模式図である。
【図１６】同実施形態における出力可否判定ルールの一例を示す模式図である。
【図１７】第３の実施形態に係る仕様書生成装置の構成を示す模式図である。
【図１８】第４の実施形態に係る仕様書生成装置の構成を示す模式図である。
【発明を実施するための形態】
【００３０】
以下、各実施形態について図面を用いて説明する。なお、以下の各図において略同一の部分については同一の符号を付してその詳しい説明を省略する。また、以下の仕様書生成装置は、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から仕様書生成装置となるコンピュータにインストールされ、仕様書生成装置の機能を実現させるための仕様書生成プログラムが用いられる。
【００３１】
（第１の実施形態）
図１は第１の実施形態に係る仕様書生成装置の構成を示す模式図である。図中の矢印は、仕様データｄ１−１〜ｄ１−３，ｄ２−１〜ｄ２−３，ｄ５−１〜ｄ５−３，ｄ６−１〜ｄ６−３、仕様要素選択状態データｄ３，ｄ４、仕様書データｄ７等のデータ又は処理の流れを示している。仕様書生成装置１０は、仕様データ記憶部１１、出力可否判定ルール記憶部１２、仕様データ読込み部１３、仕様要素選択状態データ読込み部１４、仕様書出力可否判定部１５及び仕様書生成部１６を備えている。
【００３２】
始めに、仕様データ、仕様メタ情報、仕様クラス、属性、及び仕様要素選択状態データ、フィーチャモデル等の用語について簡単に説明し、その後、各部１１〜１６について述べる。
【００３３】
ここで、仕様データｄ１−１〜ｄ１−３とは、仕様書を構成する仕様要素からなるデータであり、仕様書生成装置１０の利用者によって予め仕様メタ情報に従って作成される。仕様データを作成する利用者は、仕様データのデータ構造を定義した仕様メタ情報に従い、必要な仕様要素を定義していく。
【００３４】
仕様メタ情報は、仕様書に記載すべき仕様を、仕様の種類に応じた「仕様クラス」として定義した情報であり、特定のコアアセットの仕様ではなく、仕様書に記載すべき仕様の枠組みを定義した情報である。仕様メタ情報としては、図２に一例を示すように、機能仕様を定義するための仕様クラス「機能」、画面仕様を定義するための仕様クラス「画面」、帳票仕様を定義するための仕様クラス「帳票」などが使用可能であるが、これに限定されない。また、ある仕様クラスの実体（インスタンス）を「仕様要素」と呼ぶ。例えば、当該装置の利用者が、「利用者情報登録機能」、「利用者情報更新機能」及び「利用者情報削除機能」等の機能仕様を定義する場合、それらの機能仕様を仕様クラス「機能」の仕様要素としてそれぞれ記述することになる。
【００３５】
仕様クラスには一つ以上の属性を定義する。図２に示した例では、仕様クラス「機能」には、各仕様要素を一意に識別するための属性「機能ＩＤ」、各仕様要素の名称を記述するための属性「機能名」、各仕様要素の説明を記述するための属性「説明」を記述するよう、仕様メタ情報で定義している。なお、以下で説明する属性（名称、説明）はあくまで例示であり、仕様データｄ１−１〜ｄ１−３において、「ＩＤ」以外の属性は、仕様クラスによって異なるものである。
【００３６】
属性には、他の仕様要素への参照が定義可能である。図２に示した例では、仕様クラス「画面」の属性「関連機能ＩＤ」の値には、仕様クラス「機能」に属する仕様要素の「機能ＩＤ」を記述するよう、仕様メタ情報に定義している。なお、参照可能な仕様クラスは、参照元の仕様クラスと同一の仕様クラスでもよく、異なる仕様クラスでもよい。また、ひとつの属性から参照可能な仕様クラスの種類は二種類以上あってもよい。
【００３７】
仕様データｄ１−１は、図３（ａ）に一例を示すように、一行目が仕様メタ情報に定義された属性を示し、二行目〜四行目が「機能クラス」の仕様要素を示している。図３（ａ）には、３個の仕様要素が定義してあることになる。また、図３（ａ）は、前述の仕様メタ情報の例に従う場合の例を示しているため、仕様クラス「機能」の仕様要素では、属性「機能ＩＤ」、属性「機能名」、及び属性「説明」の値を定義する。
【００３８】
仕様データｄ１−２は、図３（ｂ）に一例を示すように、仕様クラス「画面」の仕様要素に関し、属性「画面ＩＤ」、属性「画面名」及び属性「説明」の他に、その仕様要素に関連する、仕様クラス「機能」に属する仕様要素への参照を、属性「関連機能ＩＤ」として定義可能となっている。「関連機能ＩＤ」属性には、機能クラスとして定義された機能仕様の「機能ＩＤ」を定義する。ある仕様要素が他の仕様要素を参照している場合、仕様データを読み込んだ際に、参照される仕様要素が存在しているかどうかを検証してもよい。
【００３９】
同様に、仕様データｄ１−３は、図３（ｃ）に一例を示すように、仕様クラス「帳票」の仕様要素に関し、属性「帳票ＩＤ」、属性「帳票名」、属性「説明」及び属性「関連機能ＩＤ」が定義可能となっている。
【００４０】
仕様データのデータ形式は、前述同様に、仕様メタ情報に従った仕様データを表現可能であれば、任意のデータ形式が使用可能となっている。例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）社の表計算ソフトウェアであるＥｘｃｅｌ（登録商標）を使用した表形式のデータとしてもよい。
【００４１】
仕様要素選択状態データｄ３とは、コアアセット全体の仕様データ内の各仕様要素が、ある特定のアプリケーションにおいてどのような状態であるかを示す情報であり、仕様書生成装置１０の利用者によって予め作成される。また、仕様要素選択状態データｄ３とは、コアアセットのフィーチャモデルに含まれる全てのフィーチャに対して、それぞれのフィーチャに対応する仕様要素と、どのフィーチャが特定のアプリケーションに必要であるかを示した情報であってもよい。なお、仕様要素選択状態データｄ３では，上述のようにフィーチャモデルの構造を表すことができるが、更には（個別のフィーチャに対応する）仕様要素が選択されているのか否かを知ることができるのも重要な機能である。
【００４２】
図４にフィーチャモデルの例を示す。ここでは、フィーチャ「システム」は、２つのフィーチャ「タイプ」と「仕向地」により構成される。（親）フィーチャ「タイプ」においては、代替を示す関係により、２つの（子）フィーチャ「Ａタイプ」又は「Ｂタイプ」のうちの、いずれかのフィーチャが選択される。フィーチャ「仕向地」においては、代替を示す関係により、３つのフィーチャ「日本」、「米国」、又は「中国」のうちの、いずれかのフィーチャが選択される。このフィーチャの選択は、特定のアプリケーションを構築する際に行われる。
【００４３】
図５は、図４のフィーチャモデルを表現した仕様要素選択状態データｄ３の例を示している。この仕様要素選択状態データｄ３においては、１列目〜４列目が各フィーチャとフィーチャモデルの構造を表し、５列目「関連仕様要素ＩＤ」が各フィーチャに対応する仕様要素（ＩＤ）を表し、６列目「フィーチャ選択フラグ」が特定のアプリケーションに必要なフィーチャであるか否かのフラグを表している。なお、仕様要素選択状態データｄ３には、図５に示したように、フィーチャモデルの構造も表現してもよいが、仕様要素選択状態データに必要な情報は、特定のアプリケーションにおける各仕様要素の状態を示す情報である。そのため、仕様要素選択状態データｄ３は、例えば、仕様要素を識別するための列と、ある特定のアプリケーションにおけるその仕様要素の状態を表現するための列によってのみ、構成されていてもよい。
【００４４】
また、仕様要素選択状態データｄ３は任意のデータ形式が使用可能となっている。例えば、仕様データと同様に、Ｍｉｃｒｏｓｏｆｔ社の表計算ソフトウェアであるＥｘｃｅｌを使用した表形式のデータとしてもよい。
【００４５】
以上が用語の説明である。次に、各部１１〜１６について述べる。
【００４６】
仕様データ記憶部１１は、各部１３〜１６から読出／書込可能な記憶手段であり、仕様データｄ２−１〜ｄ２−３，ｄ５−１〜ｄ５−３，ｄ６−１〜ｄ６−３を記憶する。
【００４７】
出力可否判定ルール記憶部１２は、例えば仕様書生成プログラムの実行時に図示しないＣＰＵ（出力可否判定ルールを出力可否判定ルール記憶手段に書き込む手段）から書込可能で仕様書出力可否判定部１５から読出可能な記憶手段であり、出力可否判定ルールを記憶する。
【００４８】
出力可否判定ルールは、仕様データ及び仕様要素選択状態データに基づいて導かれるものであり、仕様データ記憶部１１が記憶する仕様データ内の仕様要素のうち、どの仕様要素を仕様書として出力すべきかを、仕様データ内の仕様要素の選択状態を示す属性の値に基づいて判定するルールである。但し、出力可否判定ルールとしては、仕様データ内の仕様要素の選択状態を示す属性の値だけでなく、例えば、仕様メタ情報の構造や、仕様要素間の参照等を、どの仕様要素を仕様書として出力すべきかを判定基準にしてもよい。
【００４９】
このような出力可否判定ルールは、以下の［１］〜［４］には限定されるものではないが、本実施形態では、仕様データ記憶部１１内の仕様データｄ２−１〜ｄ２−３のうち、ＮＵＬＬ値の出力可否情報に関連付けられた判定対象の仕様要素に関し、以下の［１］〜［４］を判定するルールとしている。
【００５０】
［１］未選択を示す選択状態を含む場合には出力可否情報のＮＵＬＬ値を出力否の値に更新することを判定する。
【００５１】
［２］ＮＵＬＬ値又は選択を示す選択状態を含んでリンク情報を含まない場合には出力可否情報のＮＵＬＬ値を出力可の値に更新することを判定する。
【００５２】
［３］ＮＵＬＬ値又は選択を示す選択状態及びリンク情報を含む場合で当該リンク情報が示す関連仕様要素ＩＤに対応する他の仕様要素の出力可否情報が出力可を示すときには、当該判定対象の仕様要素の出力可否情報のＮＵＬＬ値を出力可の値に更新することを判定する。
【００５３】
［４］ＮＵＬＬ値又は選択を示す選択状態及びリンク情報を含む場合で当該リンク情報が示す関連仕様要素ＩＤに対応する他の仕様要素の出力可否情報が出力否を示すときには、当該判定対象の仕様要素の出力可否情報のＮＵＬＬ値を出力否の値に更新することを判定する。
【００５４】
また、仕様データ記憶部１１及び出力可否判定ルール記憶部１２は、同一の記憶装置内の別々の記憶領域、又は別々の記憶装置のいずれで実現してもよい。
【００５５】
仕様データ読込み部１３は、以下の各機能(f13-1)〜(f13-3)をもっている。
【００５６】
(f13-1)特定のアプリケーションの仕様書データに記述すべき仕様要素毎に、他の仕様要素から参照される参照先の仕様要素のＩＤ、名称及び説明を互いに関連付けた参照先の仕様データｄ１−１と、この参照先の仕様要素を参照する参照元の仕様要素のＩＤ、名称、説明、及び参照先の仕様要素のＩＤを示す関連仕様要素ＩＤを互いに関連付けた参照元の仕様データｄ１−２，ｄ１−３とをそれぞれ読み込む機能。なお、読み込み元は、プログラムと同様にネットワーク又は記憶媒体などが適宜、使用可能となっている。
【００５７】
(f13-2)読み込んだ各仕様データｄ１−１〜ｄ１−３のうち、参照先の仕様データｄ１−１に対し、ＮＵＬＬ値の選択状態、及びＮＵＬＬ値の出力可否情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照先の仕様データｄ２−１を仕様データ記憶部１１に書き込む機能。
【００５８】
(f13-3)読み込んだ各仕様データｄ１−１〜ｄ１−３のうち、参照元の仕様データｄ１−２，ｄ１−３に対し、特定のアプリケーションの仕様要素として選択か未選択かを示してＮＵＬＬ値の初期値をもつ選択状態、仕様書として出力可か出力否かを示してＮＵＬＬ値の初期値をもつ出力可否情報、及び関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照元の仕様データｄ２−２，ｄ２−３を仕様データ記憶部１１に書き込む機能。
【００５９】
ここで、「特定のアプリケーションの仕様要素として選択か未選択かを示してＮＵＬＬ値の初期値をもつ選択状態」を示す属性は、仕様要素ごとに設定されるものであり、特定のアプリケーションのフィーチャモデルから判断可能となっている。例えば、ある仕様要素に対応するフィーチャが、ある特定のアプリケーションに必要である場合には、その仕様要素の選択状態を示す属性の値を「選択する」（＝選択）とし、一方、その仕様要素に対応するフィーチャが、ある特定のアプリケーションに不要である場合には、その仕様要素の選択状態を示す属性の値を「選択しない」（＝未選択）とするというように、ある特定のアプリケーションのフィーチャモデルにおいて選択されたフィーチャ及び選択されていないフィーチャが、それぞれどの仕様要素に対応しているかを識別する。なお、フィーチャモデルにおける各フィーチャが全ての仕様要素に対応しているとは限らないので、選択状態を示す属性の値が空の仕様要素が存在していてもよい。
【００６０】
仕様データ記憶部１１に記憶する仕様データのデータ形式は、各部１３〜１６が解釈可能なデータ形式であればよい。例えば、各部１３〜１６をオブジェクト指向言語により実装する場合には、仕様クラスをオブジェクト指向言語のクラスに、そして、それぞれの仕様クラスに属する仕様要素をオブジェクト指向言語のインスタンスに対応させることができる。
【００６１】
また、仕様書生成装置１０が読み込んだ仕様データｄ２−１〜ｄ２−３は、表形式で表現した場合、図６（ａ）〜図６（ｃ）に示すようになる。
【００６２】
図６（ｂ）〜図６（ｃ）に示す例では、「画面」クラス及び「帳票」クラスの仕様要素のうち、「関連機能ＩＤ」として「機能」クラスの仕様要素を参照している仕様要素の「リンク情報」属性には、「関連機能ＩＤ」属性に記述された値を識別子としてもつ「機能」クラスの仕様要素へのリンク情報が記載されている。一方、他の仕様要素を参照しない「機能」クラスは、図６（ａ）に示すように、リンク情報をもたない。
【００６３】
ここで、仕様データの「リンク情報」、「選択状態」及び「出力可否」の構造については、前述した例に限らず、各仕様要素に対して、その仕様要素が参照する他の仕様要素へのリンク情報と、「選択状態」に相当する情報と、「出力可否」に相当する情報と、が対応付けられている構造であれば、任意の構造が使用可能となっている。
【００６４】
仕様要素選択状態データ読込み部１４は、以下の各機能(f14-1)〜(f14-4)をもっている。
【００６５】
(f14-1)特定のアプリケーションのフィーチャモデルにおけるフィーチャ毎に、親フィーチャのＩＤ、当該親フィーチャからみて代替又は包括を示す関係、当該フィーチャを識別するためのフィーチャＩＤ、当該フィーチャの名称を示すフィーチャ名、当該フィーチャに対応する仕様要素のＩＤを示す関連仕様要素ＩＤ、及び当該フィーチャを選択するか否かを示すフィーチャ選択フラグを互いに関連付けた仕様要素選択状態データｄ３を読み込む機能。なお、読み込み元は、プログラムと同様にネットワーク又は記憶媒体などが適宜、使用可能となっている。また、フィーチャモデルにおける代替（ｏｒ）を示す関係は、図４に示す白抜きの扇形によって表現されている。フィーチャモデルにおける包括（ａｎｄ）を示す関係は、図示しないが、黒塗りの扇形によって表現可能となっている。
【００６６】
(f14-2)読み込んだ仕様要素選択状態データｄ３に対し、フィーチャＩＤ毎に、当該フィーチャＩＤに関連付けられた関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された仕様要素選択状態データｄ４を保持する機能。
【００６７】
(f14-3)保持した仕様要素選択状態データｄ４内の関連仕様要素ＩＤ及びフィーチャ選択フラグに基づき、この関連仕様要素ＩＤに一致する仕様データ記憶部１１内の仕様データｄ２−１〜ｄ２−３の仕様要素のＩＤに関し、この仕様要素のＩＤに関連付けられた選択状態のＮＵＬＬ値を当該フィーチャ選択フラグに従って選択又は未選択を示す値に更新する機能。
【００６８】
ここで、機能(f14-3)における選択状態を更新するルールについては、当該装置内であらかじめ決めたものでもよいし、当該機能部を実行する前に当該装置の外部から読み込んだデータを解釈したものでもよい。
【００６９】
仕様書生成装置１０が読み込んだ仕様要素選択状態データｄ４を、図５に基づく表形式で表現した場合、図７に示すようになる。
【００７０】
図７に示す例では、「リンク情報」属性には、「関連仕様要素ＩＤ」属性に記述された値を識別子としてもつ仕様要素へのリンク情報が記載されている。但し、仕様要素選択状態データｄ４の「リンク情報」の構造については、これに限らず、各仕様要素選択状態データに対して、その仕様要素選択状態データｄ４が参照する他の仕様要素へのリンク情報が対応付けられている構造であれば、任意の構造が使用可能となっている。
【００７１】
仕様書出力可否判定部１５は、出力可否判定ルール記憶部１２内の出力可否判定ルールに基づいて、仕様データ記憶部１１内の仕様データｄ５−１〜ｄ５−３に含まれる出力可否情報のＮＵＬＬ値を出力可又は出力否の値に更新することを判定し、この判定結果に従って当該更新を実行する機能をもっている。
【００７２】
仕様書生成部１６は、仕様書出力可否判定部１５による更新が完了すると、仕様データ記憶部１１内の仕様データｄ６−１〜ｄ６−３のうち、出力可の値の出力可否情報に関連付けられた全ての仕様要素を抽出し、当該抽出した全ての仕様要素における仕様要素のＩＤ、名称、説明、及び関連仕様要素ＩＤが記述された仕様書データｄ７を生成する機能をもっている。
【００７３】
仕様書データｄ７のデータ形式には、例えば、Ｍｉｃｒｏｓｏｆｔ（Ｒ）社の文書作成ソフトウェアであるＷＯＲＤなどがある。また、仕様書データｄ７のレイアウトについては、例えば、仕様データと同じ表形式でも良いし、当該装置の利用者が設定したルールに従い仕様要素を加工した文書データとしても良い。
【００７４】
また、仕様書生成部１６は、抽出した全ての仕様要素を出力対象とせず、予め利用者が設定したルールに該当する仕様要素を出力対象としてもよい。
【００７５】
次に、以上のように構成された仕様書生成装置の動作について図８のフローチャートを用いて説明する。
【００７６】
仕様データ読込み部１３は、特定のアプリケーションの仕様書データに記述すべき仕様要素毎に、他の仕様要素から参照される参照先の仕様要素のＩＤ、名称及び説明を互いに関連付けた参照先の仕様データｄ１−１と、この参照先の仕様要素を参照する参照元の仕様要素のＩＤ、名称、説明、及び参照先の仕様要素のＩＤを示す関連仕様要素ＩＤを互いに関連付けた参照元の仕様データｄ１−２，ｄ１−３とをそれぞれ読み込む（ＳＴ１０）。
【００７７】
また、仕様データ読込み部１３は、読み込んだ各仕様データｄ１−１〜ｄ１−３のうち、参照先の仕様データｄ１−１に対し、ＮＵＬＬ値の選択状態、及びＮＵＬＬ値の出力可否情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照先の仕様データｄ２−１を仕様データ記憶部１１に書き込む。
【００７８】
さらに、仕様データ読込み部１３は、読み込んだ各仕様データｄ１−１〜ｄ１−３のうち、参照元の仕様データｄ１−２，ｄ１−３に対し、特定のアプリケーションの仕様要素として選択か未選択かを示してＮＵＬＬ値の初期値をもつ選択状態、仕様書として出力可か出力否かを示してＮＵＬＬ値の初期値をもつ出力可否情報、及び関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された参照元の仕様データｄ２−２，ｄ２−３を仕様データ記憶部１１に書き込む。
【００７９】
続いて、仕様要素選択状態データ読込み部１４は、特定のアプリケーションのフィーチャモデルにおけるフィーチャ毎に、親フィーチャのＩＤ、当該親フィーチャからみて代替又は包括を示す関係、当該フィーチャを識別するためのフィーチャＩＤ、当該フィーチャの名称を示すフィーチャ名、当該フィーチャに対応する仕様要素のＩＤを示す関連仕様要素ＩＤ、及び当該フィーチャを選択するか否かを示すフィーチャ選択フラグを互いに関連付けた仕様要素選択状態データｄ３を読み込む（ＳＴ２０）。
【００８０】
また、仕様要素選択状態データ読込み部１４は、読み込んだ仕様要素選択状態データｄ３に対し、フィーチャＩＤ毎に、当該フィーチャＩＤに関連付けられた関連仕様要素ＩＤを示すリンク情報を追加して関連付けるように変換処理を施し、この変換処理が施された仕様要素選択状態データｄ４を図示しないメモリ等に保持する。
【００８１】
しかる後、仕様要素選択状態データ読込み部１４は、保持した仕様要素選択状態データｄ４内の関連仕様要素ＩＤ及びフィーチャ選択フラグに基づき、この関連仕様要素ＩＤに一致する仕様データ記憶部１１内の仕様データｄ２−１〜ｄ２−３の仕様要素のＩＤに関し、この仕様要素のＩＤに関連付けられた選択状態のＮＵＬＬ値を当該フィーチャ選択フラグに従って選択又は未選択を示す値に更新する。
【００８２】
ここで、図７に示した仕様要素選択状態データｄ４の例に基づいて、各仕様要素の属性「選択状態」の値を決定するアルゴリズムの例を以下に示す。
【００８３】
（１）属性「フィーチャ選択フラグ」の値が「○」でない、全ての行の属性「関連仕様要素ＩＤ」に記載された全ての仕様要素を「選択しない」と判別する。
【００８４】
（２）属性「フィーチャ選択フラグ」の値が「○」である、全ての行の属性「関連仕様要素ＩＤ」に記載された全ての仕様要素を「選択する」と判別する。ここで、ある仕様要素が一度「選択しない」と判別されても、その後「選択する」と判別されれば、最終的に「選択する」となる。
【００８５】
上記アルゴリズムに従った場合、図６の例では、属性「選択状態」の値が「選択する」と判別される仕様要素と、「選択しない」と判別される仕様要素は、以下のようになる。
【００８６】
「選択する」：Ｆ００２，Ｆ００３，Ｖ００１，Ｖ００１−ＪＰＮ，Ｒ００２，Ｒ００２−ＪＰＮ，Ｖ００３，Ｖ００３−ＪＰＮ。
【００８７】
「選択しない」：Ｆ００１，Ｖ００１−ＵＳＡ，Ｖ００１−ＣＨＮ，Ｒ００２−ＵＳＡ，Ｒ００２−ＣＨＮ，Ｖ００３−ＵＳＡ，Ｖ００３−ＣＨＮ。
【００８８】
すなわち、仕様データ記憶部１１が記憶する仕様データｄ２−１〜ｄ２−３を仕様要素選択状態データ読込み部１４が更新した結果は、図９（ａ）〜図９（ｃ）に示すようになる。
【００８９】
ここで、仕様要素選択状態データｄ４における属性「フィーチャＩＤ」の値が「ＦＴ００１−０１」のフィーチャは選択されていないため、仕様データｄ２−１における属性「機能ＩＤ」の値が「Ｆ００２」である仕様要素の属性「選択状態」の値が、一度「選択しない」の状態になる。しかしながら、仕様要素選択状態データｄ４における属性「フィーチャＩＤ」の値が「ＦＴ００１−０２」のフィーチャが選択されているため、仕様データｄ２−１における属性「機能ＩＤ」の値が「Ｆ００２」である仕様要素の属性「選択状態」の値は、図９（ａ）に示すように、最終的に「選択する」の状態となる。
【００９０】
仕様書出力可否判定部１５は、出力可否判定ルール記憶部１２内の出力可否判定ルールに基づいて、仕様データ記憶部１１内の仕様データｄ５−１〜ｄ５−３に含まれる出力可否情報のＮＵＬＬ値を出力可又は出力否の値に更新することを判定し、この判定結果に従って当該更新を実行する（ＳＴ３０）。
【００９１】
ここで、ステップＳＴ３０で実行される処理の一例を、図１０及び図１１のフローチャートを用いて詳細に説明する。
【００９２】
仕様書出力可否判定部１５は、仕様データに含まれる仕様要素のうち、属性「出力可否」の値が「ＮＵＬＬ」である仕様要素を選択する（ＳＴ３１）。この仕様要素を「判定対象の仕様要素」とする。
【００９３】
仕様書出力可否判定部１５は、判定対象の仕様要素が存在するか否かを判定し（ＳＴ３２）、存在しなければ処理を終了し、存在すれば判定サブルーチンを実行した後（ＳＴ３３）、ステップＳＴ３１に戻る。
【００９４】
ステップＳＴ３３の判定サブルーチンにおいて、仕様書出力可否判定部１５は、判定対象の仕様要素の属性「選択状態」の値を確認する（ｓｕｂ１）。
【００９５】
ステップｓｕｂ１の確認結果が「選択しない」の場合：選択した仕様要素の属性「出力可否」の値を「否」にした後（ｓｕｂ２）、判定サブルーチンを終了してステップＳＴ３１に戻る（リターン）。
【００９６】
ステップｓｕｂ１の確認結果が「選択する」又は「ＮＵＬＬ」の場合：判定対象の仕様要素の属性「リンク情報」を参照し、その仕様要素が、他の仕様要素を参照しているかどうか判定する（ｓｕｂ３）。 
ステップｓｕｂ３の判定の結果、他の仕様要素を参照していない場合：選択した仕様要素の属性「出力可否」の値を「可」にした後（ｓｕｂ４）、判定サブルーチンを終了してステップＳＴ３１に戻る。
【００９７】
ステップｓｕｂ３の判定の結果、他の仕様要素を参照している場合：判定対象の仕様要素が参照する全ての仕様要素の属性「出力可否」の値を確認する（ｓｕｂ５）。
【００９８】
ステップｓｕｂ５の確認の結果、全て「可」の場合：判定対象の仕様要素の属性「出力可否」の値を「可」にした後（ｓｕｂ４）、判定サブルーチンを終了してステップＳＴ３１に戻る。
【００９９】
ステップｓｕｂ５の確認の結果、一つでも「否」が存在する場合：判定対象の仕様要素の属性「出力可否」の値を「否」にした後（ｓｕｂ２）、判定サブルーチンを終了してステップＳＴ３１に戻る。
【０１００】
ステップｓｕｂ５の確認の結果、「可」と「ＮＵＬＬ」が混在している場合：まず、現在の判定対象の仕様要素を、「参照元の仕様要素」として記憶しておく（ｓｕｂ６）。続いて、現在の判定対象の仕様要素が参照する仕様要素のうち、属性「出力可否」の値が「ＮＵＬＬ」の仕様要素を新たな判定対象の仕様要素として判定サブルーチンを実行した後（ｓｕｂ７〜ｓｕｂ８）、判定対象の仕様要素を参照元の仕様要素として記憶していた仕様要素に戻して（ｓｕｂ９）、再度ステップｓｕｂ５を実行する。 
図９の例では、属性「出力可否」の値が「可」と判別される仕様要素と、「否」と判別される仕様要素は、それぞれ以下のようになる。
【０１０１】
属性「出力可否」の値が「可」の仕様要素：Ｆ００２，Ｆ００３，Ｖ００１，Ｖ００１−ＪＰＮ，Ｒ００２，Ｒ００２−ＪＰＮ，Ｖ００３，Ｖ００３−ＪＰＮ。
【０１０２】
属性「出力可否」の値が「否」の仕様要素：Ｆ００１，Ｖ００１−ＵＳＡ，Ｖ００１−ＣＨＮ，Ｒ００２−ＵＳＡ，Ｒ００２−ＣＨＮ，Ｖ００３−ＵＳＡ，Ｖ００３−ＣＨＮ。
【０１０３】
すなわち、仕様データ記憶部１１が記憶する図９の仕様データｄ５−１〜ｄ５−３を仕様書出力可否判定部１５が更新した結果は、図１２の仕様データｄ６−１〜ｄ６−３のようになる。
【０１０４】
仕様書生成部１６は、仕様書出力可否判定部１５による更新が完了すると、仕様データ記憶部１１内の仕様データｄ６−１〜ｄ６−３のうち、出力可の値の出力可否情報に関連付けられた全ての仕様要素を抽出し、当該抽出した全ての仕様要素における仕様要素のＩＤ、名称、説明、及び関連仕様要素ＩＤが記述された仕様書データｄ７を生成及び出力する（ＳＴ４０）。
【０１０５】
なお、本実施形態においては、「仕様データ」及び「仕様要素選択状態データ」の論理構造を表形式で表現しているが、実装する際には表形式でなくても、この構造を表現できるような物理構造であればよい。
【０１０６】
上述したように本実施形態によれば、フィーチャモデルに基づく選択状態の属性と出力可否の属性とリンク情報とを含むように仕様データを変換し、この仕様データの出力可否の属性が出力可を示す仕様要素から仕様書データを生成する構成により、各フィーチャに対応する全ての仕様要素を容易に管理できると共に、不要な仕様要素が含まれない仕様書を容易に生成することができる。
【０１０７】
（第２の実施形態）
図１３は第２の実施形態に係る仕様書生成装置の構成を示す模式図であり、図１と同一部分については同一符号を付してその詳しい説明を省略し、ここでは異なる部分について主に述べる。なお、以下の各実施形態も同様にして重複した説明を省略する。
【０１０８】
本実施形態は、第１の実施形態の変形例であり、仕様書生成装置１０に、出力可否判定ルール読込み部１７を追加した構成により、出力可否判定ルール記憶部１１内の出力可否判定ルールを書換え可能としている。
【０１０９】
出力可否判定ルール読込み部１７は、外部から読み込んだ出力可否判定ルールを出力可否判定ルール記憶部１７に書き込むものであり、ここでは、仕様書出力可否判定部１５により仕様要素の出力可否を判定するための規則を記述した出力可否判定ルールを読み込む機能と、読み込んだ出力可否判定ルールを仕様書出力可否判定部１５が解釈可能なデータ形式に変換する機能と、変換した出力可否判定ルールを出力可否判定ルール記憶部１２に書き込む機能とをもっている。
【０１１０】
図１４は、変換した仕様データの構造の一例を表現したクラス図である。このクラス図には、仕様データ全体を表現した「仕様データ」クラス、仕様データ内の仕様要素を、仕様クラスによらずに抽象的に表現した「仕様要素」クラス、仕様クラスごとの仕様要素を表現した「仕様要素（機能）」クラス、「仕様要素（画面）」クラス、「仕様要素（帳票）」クラスが存在している。
【０１１１】
仕様データクラスの属性としては、その仕様データ内に含まれる全ての仕様要素のリストである属性「仕様要素リスト」を定義している。
【０１１２】
仕様データクラスでは、仕様要素の属性「選択状態」の値が「選択する」である、全ての仕様要素を取得する操作である「GET_SELECTED_ELEMENTS()」と、仕様要素の属性「出力可否」の値が「可」である、全ての仕様要素を取得する操作である「GET_OUTPUT_ELEMENTS()」とを定義している。
【０１１３】
仕様要素クラスの属性としては、仕様メタ情報の全ての仕様クラスに共通する属性を定義しており、その仕様要素を一意に識別するための属性である「仕様要素ＩＤ」、その仕様要素の名称を記述した属性である「仕様要素名」と、その仕様要素が所属する「仕様」クラスを示す属性である「仕様クラス種別」と、仕様データを読み込んだ際に追加した属性である「選択状態」、「出力可否」とを定義している。
【０１１４】
「仕様要素」クラスの子クラスである「仕様要素（機能）」クラスでは、その属性として、その仕様要素の説明を記述した属性である「説明」を定義し、「仕様要素（画面）」クラス及び「仕様要素（帳票）」クラスでは、その属性として、その仕様要素に関連する「仕様要素（機能）」クラスを参照する属性である「関連機能」と「説明」を、それぞれ定義している。
【０１１５】
「仕様要素」クラス、及び、その子クラスである「仕様要素（機能）」クラス、「仕様要素（画面）」クラス、そして「仕様要素（帳票）」クラスでは、その仕様要素が他の仕様要素を参照しているかどうかを、属性「リンク情報」を参照することで判定する操作「HAS_REFS()」と、属性「リンク情報」を参照し、その仕様要素が参照する全ての仕様要素を取得する操作「GET_REFS()」とを定義している。
【０１１６】
なお、クラス構造は、図１４に限定せず、仕様要素の構造が表現できていればよい。
【０１１７】
ここで、仕様書生成装置１０が読み込む出力可否判定ルールは、仕様書出力可否判定部１５における判定ルールｒ１，ｒ２を記述したものであり、例えば、図１５及び図１６に示すような形式で表現する。以下で、それぞれの出力可否判定ルールｒ１，ｒ２について説明する。
【０１１８】
始めに、図１５に示す出力可否判定ルールｒ１について述べる。
【０１１９】
１行目：関数「出力可否判定」の定義の開始を意味する。
【０１２０】
２行目：「仕様要素」クラスのインスタンス「element」を定義する。
【０１２１】
３行目：「仕様データ」クラスのメソッド「GET_SELECTED_ELEMENTS()」により取得した全ての仕様要素について、それぞれ、変数「element」に代入して４行目の処理を実行する。ここで、メソッド「GET_SELECTED_ELEMENTS()」は、前述のとおり、「仕様データ」クラスのメソッドであり、仕様データ内の仕様要素のうち、属性「選択状態」の値が「選択する」の意味である、全ての仕様要素を取得するものである。
【０１２２】
４行目：変数「element」を引数として、後述の関数「判定サブルーチン」を実行する。
【０１２３】
５行目：３行目で定義した繰り返し処理が、ここで終了していることを意味する。
【０１２４】
６行目：関数を終了する。
【０１２５】
７行目：関数「出力可否判定」の定義の終了を意味する。
【０１２６】
続いて、図１６に示す出力可否判定ルールｒ２について述べる。
【０１２７】
１行目：関数「判定サブルーチン」の定義の開始を意味する。引数は「仕様要素」クラスのインスタンス「element」である。
【０１２８】
２行目：「仕様要素」クラスのインスタンス「ref_element」を定義する。
【０１２９】
３行目：変数「ref_element」の属性「選択状態」の値が「未選択」の場合、４行目の処理を実行する。
【０１３０】
４行目：変数「element」の属性「出力可否」の値を「否」にして、関数を終了する。
【０１３１】
５行目：３行目の条件を満たさない場合、６行目からの処理を実行する。
【０１３２】
６行目：変数「element」のメソッド「HAS_REFS()」により取得した値が「FALSE」の場合、７行目の処理を実行する。ここで、メソッド「HAS_REFS()」は、前述のとおり、「仕様要素」クラスのメソッドであり、変数「element」が他の仕様要素を参照しているかどうかを返すものである。
【０１３３】
７行目：変数「element」の属性「出力可否」の値を「可」にして、関数を終了する。
【０１３４】
８行目：６行目の条件を満たさない場合、９行目からの処理を実行する。
【０１３５】
９行目：「仕様要素」クラスのメソッド「GET_REFS()」により取得した全ての仕様要素について、それぞれ、変数「ref_element」に代入して１０行目からの処理を実行する。ここで、メソッド「GET_REFS()」は、前述のとおり、「仕様要素」クラスのメソッドであり、当該仕様要素が参照する全ての仕様要素を取得するものである。
【０１３６】
１０行目：変数「ref_element」の属性「出力可否」の値が「ＮＵＬＬ」の場合、１１行目の処理を実行する。
【０１３７】
１１行目：変数「ref_element」を引数として、関数「判定サブルーチン」を実行する。
【０１３８】
１２行目：１０行目で定義した条件文の終了を意味する。
【０１３９】
１３行目：変数「ref_element」の属性「出力可否」の値が「否」の場合、１４行目の処理を実行する。
【０１４０】
１４行目：変数「element」の属性「出力可否」の値を「否」にして、関数を終了する。
【０１４１】
１５行目：１３行目で定義した条件文の終了を意味する。
【０１４２】
１６行目：９行目で定義した繰り返し処理が、ここで終了していることを意味する。
【０１４３】
１７行目：変数「element」の属性「出力可否」の値を「可」にする。
【０１４４】
１８行目：６行目で定義した条件文の終了を意味する。
【０１４５】
１９行目：３行目で定義した条件文の終了を意味する。
【０１４６】
２０行目：関数を終了する。
【０１４７】
２１行目：関数「判定サブルーチン」の定義の終了を意味する。
【０１４８】
出力可否判定ルール読込み部１７が、出力可否判定ルールｒ１，ｒ２を読み込む順序については、仕様書出力可否判定部１５が、出力可否判定ルール記憶部１２から出力可否判定ルールを取得する以前であればよい。
【０１４９】
以上のような構成によれば、第１の実施形態の動作に加え、出力可否判定ルール読込み部１７が、外部から読み込んだ出力可否判定ルールを出力可否判定ルール記憶部１７に書き込むので、出力可否判定ルール記憶部１７内の出力可否判定ルールを書き換えることができる。
【０１５０】
（第３の実施形態）
図１７は第３の実施形態に係る仕様書生成装置の構成を示す模式図である。
【０１５１】
本実施形態は、第１の実施形態の変形例であり、仕様書生成装置１０に、利用者対話部１８を追加した構成により、仕様書データｄ７を構成する仕様要素を利用者が判定できる形態を示している。
【０１５２】
利用者対話部１８は、以下の各機能(f18-1)〜(f18-3)をもっている。
【０１５３】
(f18-1)ステップＳＴ３０の仕様書出力可否判定部１５による更新が完了すると、ステップＳＴ４０の仕様書生成部１６による仕様書データｄ７の生成よりも先行して、仕様書出力可否判定部１５による更新結果を出力することにより、当該更新結果の修正内容と修正命令、又は仕様書生成部１６の起動命令の入力を促す機能。
【０１５４】
(f18-2)更新結果の修正内容と修正命令の入力を受け付けると、当該修正内容と修正命令に基づいて当該更新結果を修正する機能。
【０１５５】
(f18-3)起動命令の入力を受け付けると、仕様書生成部１６を起動する機能。
【０１５６】
なお、利用者対話部１８は、例えば、出力可否判定ルール記憶部１２において「ある特定の仕様クラスに属する仕様要素の出力可否を利用者に問い合わせる」というルールを記載しておくことで、特定の仕様クラスに属する仕様要素の出力可否に、利用者の判定を反映可能な機能部として実現してもよい。
【０１５７】
以上のような構成によれば、第１の実施形態のステップＳＴ３０とＳＴ４０との間において、利用者対話部１８が、仕様書出力可否判定部１５による更新結果を出力することにより、当該更新結果の修正内容と修正命令、又は仕様書生成部１６の起動命令の入力を促す。このとき、利用者対話部１８は、更新結果の修正内容と修正命令の入力を受け付けると、当該修正内容と修正命令に基づいて当該更新結果を修正する。また、利用者対話部１８は、起動命令の入力を受け付けた場合には、仕様書生成部１６を起動する。
【０１５８】
このように、利用者対話部１８が、仕様書出力可否判定部１５による更新結果を出力することにより、当該更新結果の修正内容と修正命令などの入力を促すようにしたので、仕様書データｄ７を構成する仕様要素を利用者が判定することができる。
【０１５９】
（第４の実施形態）
図１８は第４の実施形態に係る仕様書生成装置の構成を示す模式図である。
【０１６０】
本実施形態は、第２及び第３の実施形態を組み合わせた例であり、第２の実施形態の仕様書生成装置１０に、第３の実施形態の利用者対話部１８を追加した構成により、出力可否判定ルール記憶部１７内の出力可否判定ルールを書き換えることができると共に、仕様書データｄ７を構成する仕様要素を利用者が判定できる形態を示している。
【０１６１】
以上のような構成によれば、第２及び第３の実施形態の作用効果を同時に得ることができる。
【０１６２】
以上説明した少なくとも一つの実施形態によれば、フィーチャモデルに基づく選択状態の属性と出力可否の属性とリンク情報とを含むように仕様データを変換し、この仕様データの出力可否の属性が出力可を示す仕様要素から仕様書データを生成する構成により、各フィーチャに対応する全ての仕様要素を容易に管理できると共に、不要な仕様要素が含まれない仕様書を容易に生成することができる。
【０１６３】
また、各実施形態によれば、ドメイン開発プロセスにおけるコアアセット開発者においては、フィーチャと仕様要素との対応関係の管理が容易になるため、ソフトウェア開発プロセスの生産性、品質及びリードタイムを向上させることができる。
【０１６４】
さらに、各実施形態によれば、アプリケーション開発プロセスにおけるアプリケーション開発者においては、コアアセットに含まれる仕様要素から必要な仕様要素だけを記述した仕様要素を容易に得ることができ、もって、ソフトウェア開発プロセスの生産性、品質及びリードタイムを向上させることができる。
【０１６５】
なお、上記の各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【０１６６】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【０１６７】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。
【０１６８】
さらに、各実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶又は一時記憶した記憶媒体も含まれる。
【０１６９】
また、記憶媒体は１つに限らず、複数の媒体から上記の各実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【０１７０】
なお、各実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記の各実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【０１７１】
また、各実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【０１７２】
なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１７３】
１０…仕様書生成装置、１１…仕様データ記憶部、１２…出力可否判定ルール記憶部、１３…仕様データ読込み部、１４…仕様要素選択状態データ読込み部、１５…仕様書出力可否判定部、１６…仕様書生成部、１７…出力可否判定ルール読込み部、１８…利用者対話部、ｄ１−１〜ｄ１−３，ｄ２−１〜ｄ２−３，ｄ５−１〜ｄ５−３，ｄ６−１〜ｄ６−３…仕様データ、ｄ３，ｄ４…仕様要素選択状態データ、ｄ７…仕様書データ。
【図１】
2012053567.tif 000003
【図２】
2012053567.tif 000004
【図３】
2012053567.tif 000005
【図４】
2012053567.tif 000006
【図５】
2012053567.tif 000007
【図６】
2012053567.tif 000008
【図７】
2012053567.tif 000009
【図８】
2012053567.tif 000010
【図９】
2012053567.tif 000011
【図１０】
2012053567.tif 000012
【図１１】
2012053567.tif 000013
【図１２】
2012053567.tif 000014
【図１３】
2012053567.tif 000015
【図１４】
2012053567.tif 000016
【図１５】
2012053567.tif 000017
【図１６】
2012053567.tif 000018
【図１７】
2012053567.tif 000019
【図１８】
2012053567.tif 000020