(57)【要約】      （修正有）【課題】要求仕様に含まれる条件を抜け漏れのないように探索することにより、要求仕様に含まれる不備を排除することができる自然言語記述検証装置を提供する。【解決手段】仕様を構文解析して、仕様文と格解析情報、モダリティ情報及び係り受け情報を抽出し、仕様文を単位仕様文に分割し、格解析情報を適用して、要求分析モデル要素の生成を行う要求分析モデル要素生成部と、付随するモダリティ情報を用いて要求分析モデル要素を変換し、係り受け情報を用いてつなぎ合わせて、要求分析モデルを構築する要求分析モデル構築部と、条件のモダリティ情報を持つ要求分析モデルのノードとエッジを取り出し、条件情報を生成する条件情報作成部と、条件情報を用いて複数条件を持つ仕様文を見つけ、複数条件情報として生成する複数条件情報作成部と、複数条件情報から仕様上に書かれていない条件を抜け漏れ条件情報として作成する条件の抜け漏れ情報作成部とを、備える。【選択図】図１
2015014827.tif 000002
【特許請求の範囲】
【請求項１】
仕様を構文解析して、前記仕様を構成する仕様文と格解析情報、モダリティ情報及び係り受け情報を抽出し、前記仕様文を単位仕様文に分割して、該単位仕様文へ前記格解析情報を適用して、要求分析モデルを構成する要求分析モデル要素の生成を行う要求分析モデル要素生成部と、
前記要求分析モデル要素に付随する前記モダリティ情報を用いて、前記要求分析モデル要素を変換し、変換した要求分析モデル要素を前記係り受け情報を用いてつなぎ合わせて、要求分析モデルを構築する要求分析モデル構築部と、
前記要求分析モデルから、条件の前記モダリティ情報を持つ前記要求分析モデルのノードとエッジを取り出し、条件情報を生成する条件情報作成部と、
前記条件情報を用いて複数条件を持つ前記仕様文を見つけ、複数条件情報として生成する複数条件情報作成部と、
前記複数条件情報から前記仕様上に書かれていない条件を抜け漏れ条件情報として作成する条件の抜け漏れ情報作成部とを、
備える自然言語記述検証装置。
【請求項２】
前記要求分析モデル構築部では、前記係り受け情報によって変換した前記要求分析モデル要素をエッジ要素で接続し、変換後の前記要求分析モデル要素が同じノード要素を統合して前記要求分析モデルを構築する請求項１記載の自然言語記述検証装置。
【請求項３】
前記条件情報は、
取得したノードまたはエッジが、特定パターンと一致する場合に、前記要求分析モデルから、条件を構成する主体と状態、仕様文の主節、その条件が現れる前記仕様文への参照の各値を取得し、
条件を構成する主体と状態と、その条件が現れる前記仕様文への参照を行に持つ表である条件表と、
条件文が現れる前記仕様文への参照と、該仕様文が持つ主節を行に持つ表である仕様文-主節表である請求項１又は請求項２記載の自然言語記述検証装置。
【請求項４】
前記特定パターンは、
ノードが条件の前記モダリティ情報を持ち、ノードがエッジを出力し、エッジにターゲットノードがあるパターンであり、
主体は、条件の前記モダリティ情報を持つノードの要素名、状態は、ノードの出力エッジの要素名、主節は、エッジのターゲットノードの要素名、前記仕様文への参照は、条件の前記モダリティ情報を持つノードに付属する前記単位仕様文への参照から得た前記仕様文への参照の各値である請求項３記載の自然言語記述検証装置。
【請求項５】
前記特定パターンは、
ノードとエッジが条件の前記モダリティ情報を持っており、エッジにターゲットノードがあるパターンであり、
主体は、条件の前記モダリティ情報を持つノードの要素名、状態は、条件の前記モダリティ情報を持つエッジの要素名、主節は、エッジのターゲットノードから参照できる前記単位仕様文、前記仕様文への参照は、条件の前記モダリティ情報を持つノードに付属する前記単位仕様文への参照から前記得た仕様文への参照の各値である請求項３記載の自然言語記述検証装置。
【請求項６】
前記特定パターンは、ユーザが任意に定義可能である請求項３記載の自然言語記述検証装置。
【請求項７】
前記複数条件情報は、複数条件となる主体集合と、複数条件となる前記仕様文への参照を列名とする複数条件表であって、
該複数条件表は、主体の列には主体が取り得る状態が入り、行は複数条件に現れる状態の組み合わせと、そのときの前記仕様文への参照を表すものである請求項１乃至請求項６のいずれか１項に記載の自然言語記述検証装置。
【請求項８】
前記複数条件表の列名と等しい、又は、内包する別の前記複数条件表があるとき、それらを結合処理し、統合複数条件表とする請求項７記載の自然言語記述検証装置。
【請求項９】
前記抜け漏れ条件情報は、
前記統合複数条件表の中で、前記仕様文への参照を持たない行を登録するもので、複数条件となる主体集合と、IDを列名とする未記述条件表と、
前記未記述条件表の行ごとに割り当てられたIDと主節候補の集合の対応付けから成る主節候補のデータである請求項８記載の自然言語記述検証装置。
【請求項１０】
前記未記述条件表では、行は複数条件に現れる状態の組み合わせと、各行ごとに固有のIDが入る請求項９記載の自然言語記述検証装置。
【請求項１１】
前記主節候補は、前記抜け漏れ条件に続く主節になるか、又は、前記抜け漏れ条件に続く主節と矛盾した関係ではない内容であることを示すものである請求項９又は請求項１０記載の自然言語記述検証装置。
【請求項１２】
前記抜け漏れ条件情報は、
前記未記述条件表の行のIDと同じIDを持つ前記主節候補のデータからIDに対応付けられた主節を取得し、前記抜け漏れ条件の前記主節候補として示すもので、ユーザ提示用の表示データである請求項１１記載の自然言語記述検証装置。
【請求項１３】
前記ユーザ提示用の表示データの形式は、ユーザが任意に設定可能である請求項１２記載の自然言語記述検証装置。
【請求項１４】
前記生成した仕様文、前記モダリティ情報、対にした前記単位仕様文と分配された前記モダリティ情報、前記モダリティ情報と係り受け情報を付与した前記要求分析モデル要素、前記変換後の要求分析モデル要素のそれぞれを記憶する記憶装置を備える請求項１乃至請求項１３のいずれか１項に記載の自然言語記述検証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、自然言語記述検証装置に関する。
【背景技術】
【０００２】
ソフトウェア開発では、自然言語で記述された要求仕様を自然言語解析し、その結果を元にソフトウェアを構築している。
【０００３】
近時、システムの大規模化、システム間の機能統合などにより開発するシステムの要求が増加している。ソフトウェア開発は、システムの要求に伴って、大規模、複雑化している。開発において、上流工程での要求仕様の不備は、下流工程で不具合として頻発することとなる。そのため、手戻りコストとなり、開発遅延や品質劣化へ影響する。
【０００４】
自然言語の要求仕様に記述されている条件が網羅的に書かれていないとき、仕様の抜け漏れによりシステムの予期せぬ動作や不具合に繋がる。
【０００５】
大量の要求仕様から、仕様の不備を含む箇所を見つけることは容易ではない。要求仕様に含まれる条件の不備を把握することは難しく、人手により大量の仕様から条件の記述を抽出し、条件が持つ主体と状態を見つけ、抜けている条件を探索するには、コストがかかり、容易でない、という問題があった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−２２７６９５号公報
【特許文献２】特開２００８−３１０６６３号公報
【特許文献３】特開２００９−１２３１１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明が解決しようとする課題は、要求仕様に含まれる条件を抜け漏れのないように探索することにより、要求仕様に含まれる不備を排除することができる自然言語記述検証装置を提供することである。
【課題を解決するための手段】
【０００８】
実施形態の自然言語記述検証装置は、仕様を構文解析して、前記仕様を構成する仕様文と格解析情報、モダリティ情報及び係り受け情報を抽出し、前記仕様文を単位仕様文に分割して、該単位仕様文へ前記格解析情報を適用して、要求分析モデルを構成する要求分析モデル要素の生成を行う要求分析モデル要素生成部と、前記要求分析モデル要素に付随する前記モダリティ情報を用いて、前記要求分析モデル要素を変換し、変換した要求分析モデル要素を前記係り受け情報を用いてつなぎ合わせて、要求分析モデルを構築する要求分析モデル構築部と、前記要求分析モデルから、条件の前記モダリティ情報を持つ前記要求分析モデルのノードとエッジを取り出し、条件情報を生成する条件情報作成部と、前記条件情報を用いて複数条件を持つ前記仕様文を見つけ、複数条件情報として生成する複数条件情報作成部と、前記複数条件情報から前記仕様上に書かれていない条件を抜け漏れ条件情報として作成する条件の抜け漏れ情報作成部とを、備える。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に係る自然言語記述検証装置の概略構成を示すブロック図である。
【図２】実施形態に係る自然言語記述検証装置における要求仕様内の抜け漏れ条件の取得処理の流れを示すフローチャートである。
【図３】構文解析による仕様文の生成・単位仕様文への分割・要求分析モデル要素の生成までの処理を説明する図である。
【図４】要求分析モデル要素を説明する図である。
【図５】生成パターンがマッチした場合の要求分析モデル要素への変換処理例を示す図である。
【図６】モダリティ情報によって変換した要求分析モデル要素を示す図である。
【図７】係り受け情報を用いた係り受け接続ルールによる要求分析モデル要素の接続例を示す図である。
【図８】変換後の要求分析モデル要素の統合を説明する図である。
【図９】要求仕様内の条件の不備を模式的に説明する図である。
【図１０】特定パターンを利用した“主体”、“状態”、“主節”、“仕様文への参照”の各値の取得を説明する図である。
【図１１】条件表の一例を示す図である。
【図１２】仕様文-主節表の一例を示す図である。
【図１３】条件情報の作成処理の流れを示すフローチャートである。
【図１４】複数条件表の一例を示す図である。
【図１５】統合複数条件表の一例を示す図である。
【図１６】統合複数条件表の作成処理の流れを示すフローチャートである。
【図１７】条件の抜け漏れ情報の作成を説明する図である。
【図１８】ユーザへの表示用データの一例を示す図である。
【図１９】条件の抜け漏れ情報及び表示用データ作成処理の流れを示すフローチャートである。
【図２０】要求分析モデル要素生成部で生成された要求分析モデル要素の一例を示す図である。
【図２１】要求分析モデル構築部において作成された要求分析モデルの一例を示す図である。
【図２２】統合要求分析モデルを元に作成された条件表及び仕様文−主節表の一例を示す図である。
【図２３】複数条件情報作成部において作成された複数条件表の一例を示す図である。
【図２４】結合処理された統合複数条件表の一例を示す図である。
【図２５】作成された抜け漏れ条件情報の一例を示す図である。
【図２６】抜け漏れ条件に続く主節の候補を文形式で表示した一例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１１】
まず、本実施形態で用いる主要な用語について説明する。
【００１２】
「文」とは、自然言語で記述された句点から句点の間の文字列をいう。文は、文節という構造で構成されており、文節は句という構造で構成されている。
【００１３】
「条件文」は、条件部と主節から構成されるものをいう。条件文の中で、それだけで独立した文になれる部分を主節という。
【００１４】
「条件部」とは、1つまたは2つ以上の条件節から構成されるものをいう。
【００１５】
「条件節」は、主体と状態の組を1つ持つ。主体とは、条件節の中で、主語または主部とそれらを修飾する修飾語または修飾部にあたる部分をいう。状態とは、条件節の中で、述語または述部とそれらを修飾する修飾語または修飾部あたる部分をいう。状態は、主体に対する水準となる。一般的に条件節は、順節の働きを持つ接続助詞「ば」「と」「たら」「なら」を含むが、本実施形態では、条件節であるかどうかの判定は外部で設定し、必ずしも順節の接続助詞を含まない。
【００１６】
「複数条件文」とは、複数条件と主節から構成されるものをいう。複数条件は、条件部が2つ以上の条件節から構成されるとき、2つ以上の条件節を言う。
【００１７】
「用語」とは、文節を構成する単語で、最後尾の単語を正規化した文字列をいう。「用語」は、後述する影響関係モデルを構成するノード要素の要素名にあたる。
【００１８】
「仕様」とは、「文」が１つ以上集まった要素をいう。
【００１９】
「仕様書」とは、「仕様」の集まりをいう。ドキュメントが複数にまたがっていても「仕様書」と呼ぶ。
【００２０】
「仕様文」とは、構文解析にかけられる「文」とその解析結果をまとめあげる構成データをいう。解析結果は「文」、「文節」、「句」のレベルで特定することができる。
【００２１】
「係り受け解析」とは、語句の間にある、“修飾する”あるいは“修飾される”関係を抽出する手法をいう。解析結果は、文としての解析結果、文節ごとの解析結果、句ごとの解析結果で構成される。「係り受け解析」では、述語項の構造を解析する格解析が必要となる場合がある。
【００２２】
「モダリティ」とは、文や用語に格関係以外の情報を付与するものをいう。言語学的には副詞などの品詞による影響、テンス、ヴォイス、ムード、アスペクト、否定や提題といった情報が「モダリティ」にあたる。「モダリティ」情報が欠けると、文の意図が抜け落ちる。
【００２３】
「要求分析モデル」とは、「仕様書」の内容をグラフ構造の図として表現したものをいう。図は、ノード要素とエッジ要素の組合せで記述される。ノード要素とエッジ要素はそれぞれいくつかの表記形式（図形）を用いることができる。このため、図は各要素の表記形式とそれらの結合関係で「仕様書」の内容をモデル化する。
【００２４】
本実施形態においては、仕様書に含まれる全ての仕様を構文解析して要求分析モデル要素を生成し、生成された要求分析モデル要素を仕様書の中に存在するモダリティ情報を用いて変換し、変換した要求分析モデル要素を結び付けて要求分析モデルを構築し、要求分析モデルから条件を表すノードまたはエッジを見つけ、存在し得る条件の組み合わせを見つけ、要求仕様内の抜け漏れ条件を取得・提示するものである。
【００２５】
図１は、本発明の実施形態に係る自然言語記述検証装置の概略構成を示すブロック図である。この装置は汎用のコンピュータ（例えばパーソナルコンピュータ（ＰＣ）等）と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）に好適なエンジニアリングワークステーション（ＥＷＳ）等も含む。本実施形態はこのようなコンピュータに、要求分析モデルの構築から要求仕様内の抜け漏れ条件の取得に係る一連の手続きを実行させるプログラムとして実施することもできる。
【００２６】
図１に示すように、本実施形態に係る自然言語記述検証装置１は、主として、要求分析モデル要素生成部１０、要求分析モデル構築部２０、条件情報作成部３０、複数条件情報作成部４０、条件の抜け漏れ情報作成部５０から構成されている。要求分析モデル要素生成部１０、要求分析モデル構築部２０は、要求分析モデル構築を担うものである。条件情報作成部３０、複数条件情報作成部４０は、条件探索を担うものである。条件の抜け漏れ情報作成部５０は、条件の抜け漏れ提示を担うものである。
【００２７】
要求分析モデル要素生成部１０は、（１）仕様書、例えばソフトウェアの仕様書の入力、（２）構文解析による仕様書中に存在する文の一つ一つから仕様を構成する仕様文への変換、（３）仕様文の構文解析による、格解析情報、モダリティ情報及び係り受け情報の抽出、（４）分割が不可能と判定されるまでの単位仕様文への分割、（５）単位仕様文への格解析情報の適用による、所定の変換パターンを利用した要求分析モデル要素の生成、を行う。
【００２８】
要求分析モデル構築部２０は、要求分析モデル要素に付随するモダリティ情報を用いて、要求分析モデル要素を変換し、変換した要求分析モデル要素を係り受け情報を用いてつなぎ合わせて、要求分析モデルを構築する。
【００２９】
条件情報作成部３０は、要求分析モデルからモダリティ情報を基に、条件を表す要求分析モデルのノードとエッジを取り出し、条件情報を生成する。
【００３０】
複数条件情報作成部４０は、条件情報を用いて複数条件を持つ仕様文を見つけ、複数条件情報として生成する。
【００３１】
条件の抜け漏れ情報作成部５０は、複数条件情報から仕様上に書かれていない条件を抜け漏れ条件情報として作成し、抜け漏れ条件に続く主節の候補を用意し、ユーザに提示する。
【００３２】
次に、以上のように構成された自然言語記述検証装置１における要求仕様内の抜け漏れ条件の取得処理の流れについて説明する。
【００３３】
図２は、実施形態に係る自然言語記述検証装置における要求仕様内の抜け漏れ条件の取得処理の流れを示すフローチャートである。ここでは、処理の概要を述べ、処理の詳細は後述する。
【００３４】
まず、入力した仕様を構文解析し、仕様を構成する仕様文とモダリティ情報の抽出を行う。仕様文を単位仕様文まで分割し、格解析情報を用いて単位仕様文から要求分析モデル要素を生成する。モダリティ情報は、対応する要求分析モデル要素に付随していく（ステップＳ２１）。
【００３５】
次に、要求分析モデル要素に付随するモダリティ情報を用いて要求分析モデル要素を変換する。言語解析の結果から得られる係り受け情報によって変換した要求分析モデル要素をエッジ要素で接続し、変換後の要求分析モデル要素が同じノード要素を統合して要求分析モデルを構築する（ステップＳ２２）。
【００３６】
続いて、要求分析モデルからモダリティ情報を基に条件を表す要求分析モデルのノードとエッジを取り出し、いずれも後述する条件表と仕様文-主節表を作成する（ステップＳ２３）。
【００３７】
次に、条件表を用いて、同じ仕様に存在する条件を取り出し、後述する複数条件表を作成する（ステップＳ２４）。
【００３８】
次に、複数条件表から仕様文への参照がない条件を取り出し、後述する未記述条件表を作成する。未記述条件表に登録した条件に続く主節の候補として主節候補データを作成する。作成した未記述条件表と主節候補データを利用し、ユーザへ提示する形式へ変換して、表示用データを生成する（ステップＳ２５）。
【００３９】
上記したステップＳ２１からステップＳ２２は要求分析モデル構築に係る処理であり、ステップＳ２３からステップＳ２４は、条件探索に係る処理である、ステップＳ２５は、条件の抜け漏れ提示に係る処理である。
【００４０】
次に、構文解析による仕様文の生成・単位仕様文への分割・要求分析モデル要素の生成・要求分析モデルの構築までの処理を説明する。図３は、構文解析による仕様文の生成・単位仕様文への分割・要求分析モデル要素の生成までの処理を説明する図である。
【００４１】
＜仕様文の生成＞
図３に示す仕様書の例では、「（仕様１）蓋センサが3sec以上onとなったら、蓋が閉じられたと判断する。」という仕様を構文解析して、仕様文を生成する。日本語の構文解析は、主に文節間の係り受け構造を発見することである。係り受け解析をはじめとする構文解析により生成された仕様文は、
（仕様文１）
“蓋センサ”、“３sec以上on”、“なる”、“蓋”、“閉じられる”、“判断する”の仕様文を構成する要素から成り立っている。構文解析の際に生成されるモダリティ情報は、「条件」である。各々の要素は図３中の実線のように関わりあっている。
【００４２】
＜構文解析の解析結果＞
構文解析の解析結果は、後述する仕様文の分割処理と変換処理で利用するために必要なデータである。例えば、係り受け解析を行う周知の言語解析器であるKNPの出力データがそれに該当する。以降の説明では、KNPの出力データを例にとって説述する。
【００４３】
格解析情報：仕様文の主要述語に対する係り受けに関与する係助詞の情報である。別言すれば、係り語、係られる語及び係り方を保持する情報であるが、利用する言語解析器に依存する、自由度があるものである。
【００４４】
モダリティ情報：品詞や接続詞といった機能語、および、特殊な意味を持つ用語の情報。変換パターンの内容によって取得するデータは異なる。また複数の要素を同一の情報として取り扱うことや、複数の要素で異なるモダリティ情報として取り扱うことも可能。
【００４５】
係り受け情報：文節の係り受け関係の情報。分割処理でも利用する。
【００４６】
尚、上記したこれらの情報は、日本語等の言語の種別に制約されず、どの自然言語からも取得することができる。
【００４７】
解析結果のデータの中で、以下のようなデータをモダリティと判断し、モダリティ情報として抽出する。
【００４８】
（１）言語解析器が判定したモダリティ情報（例：＜可能表現＞、＜否定表現＞、＜態：受動＞など）
（２）言語解析器が抽出した構文情報の組合せでモダリティ情報を含むと判断されるもの（例：＜ID：〜が＞、＜テモ＞、など）
（３）言語解析器が抽出した単語要素の組合せでモダリティ情報を含むと判断されるもの（例：「従来」、「時」、「場合」、など）
（４）上記（１）〜（３）までの組合せ
モダリティ情報の抽出された情報から、次のように、モダリティを判断する。
【００４９】
＜否定表現＞ → ＜否定＞モダリティ
＜ID：〜が＞ → ＜逆接＞モダリティ
「場合」 → ＜条件＞モダリティ
＜ため-せい＞AND＜ID：〜ため＞ → ＜原因＞モダリティ
生成した仕様文及び抽出したモダリティ情報は、記憶装置（図示しない）に保存する。
【００５０】
＜単位仕様文への分割＞
仕様文を構成している要素を要求分析モデルに変換できる粒度に、仕様文を分割する。図３に示した仕様文１に対して分割処理を施すことによって、２つの単位仕様文が出来ている。単位仕様文１−２では、モダリティ情報は抽出されていない。単位仕様文には、述語がひとつしか含まれない。
【００５１】
仕様文の分割処理は、仕様文の持つ解析結果で分割パターンに一致する場合、当該仕様文を単位仕様文に分割する。分割ルールとなる分割パターンは、ユーザによって設定可能である。分割パターンは、記憶装置（図示しない）に保存する。
【００５２】
＜モダリティ分配＞
モダリティ情報は言語解析結果の文節ごとに保持されているため、分割された仕様文ごとにモダリティ情報を保持させることができる。仕様文が分割される際に、仕様文が持つモダリティ情報を分配する処理を、モダリティ分配という。モダリティ分配ルールは、ユーザが自由に設定可能である。モダリティ分配ルールは、記憶装置（図示しない）に保存する。
【００５３】
＜要求分析モデル要素＞
図４は、要求分析モデル要素を説明する図である。要求分析モデル要素は、単位仕様文と一対一で結びついている。上述したように、モダリティ情報は単位仕様文に分配されているので、要求分析モデル要素が持つモダリティ情報も分配されたものとなる。
【００５４】
図４に示すように、要求分析モデル要素は、データフローダイヤグラムの形式で表現することができる。データフローダイヤグラムは、「データストア」、「プロセス」及び「データフロー」によって、データの流れを示す矢印で繋いだ図である。
【００５５】
要求分析モデル要素は、ノードとエッジで構成する。ノードとエッジは、要求仕様に現れるオブジェクト、データ、状態や処理などとそれらをつなぐ関係を表すものである。
【００５６】
単位仕様文から要求分析モデル要素へ変換するパターンは、ユーザが設定可能であることから、ノードとエッジの持つ意味についてはユーザが決定することができる。
【００５７】
ノードは、“要素名”、“要素タイプ”、“出現箇所データ”から構成される。“要素名”は、内部モデル要素を一意に識別するための文字列である。“要素タイプ”は、特段の制限なく定義可能で、プロセス、データストア等、他の部品が混じっても構わない。“出現箇所データ”は、この要素が含まれる仕様文の識別子を全て保存しておく。
【００５８】
エッジは、“要素名”、“要素タイプ”、“ソースノード名”、“ターゲットノード名”から構成される。“要素名”は、内部モデル要素を一意に識別するための文字列である。“要素タイプ”は、エッジならば特段の制限なく定義可能で、データフロー等、他の部品が混じっても構わない。“ソースノード名”は、エッジの尾側のノード名の文字列である。“ターゲットノード名”は、エッジの頭側のノード名の文字列である。
【００５９】
要求分析モデル要素には、以下のデータが付随する。
【００６０】
（ａ）単位仕様文への参照：生成元となっている単位仕様文データへの参照
（ｂ）モダリティ情報：単位仕様文に分配されたモダリティ情報
（ｃ）係り受け情報：単位仕様文間の係り受け情報
本実施形態では、単位仕様文データに仕様文への参照のデータを持たせる。
【００６１】
＜要求分析モデル要素の生成＞
格解析情報から要求分析モデル要素を生成する処理について説明する。ここでの生成処理は、単位仕様文の解析結果の格解析情報に生成パターンとマッチするデータがある場合、要求分析モデル要素に変換するものである。
【００６２】
まず、生成処理に際して利用する、生成パターンについて説明する。生成パターンそのものは、ユーザが設定可能である。例えば、ガ格パターン、ニ格・ガ格パターン、ニ格・ガ格・ヲ格パターン、述語＋格パターンである。ガ格パターンでは、仕様文の解析結果が「*<係：ガ格>*」という正規表現にマッチするか否かを判定する。ニ格・ガ格パターンでは、仕様文の解析結果が「*<係：ガ格>*<係：ニ格>*」又は「*<係：ニ格>*<係：ガ格>*」という正規表現にマッチするか否かを判定する。ニ格・ガ格・ヲ格パターンでは、仕様文の解析結果が「*<係：ガ格>*<係：ニ格>*<係：ヲ格>*」、「*<係：ニ格>*<係：ガ格>*<係：ヲ格>*」、「*<係：ヲ格>*<係：ガ格>*<係：ニ格>*」、「*<係：ヲ格>*<係：ニ格>*<係：ガ格>*」、「*<係：ガ格>*<係：ヲ格>*<係：ニ格>*」、「*<係：ニ格>*<係：ヲ格>*<係：ガ格>*」という正規表現のいずれかにマッチするか否かを判定する。述語＋格パターンでは、述語の意味までを含めてパターンとする。例えば、「要求する」＋「*<係：ヲ格>*」のような表現にマッチするか否かを判定する。上述した生成パターンは、表層格のパターンのみを記しているが、深層格のパターンも利用可能である。
【００６３】
次に、生成パターンとのマッチングについて説明する。図５は、生成パターンがマッチした場合の要求分析モデル要素への変換処理例を示す図である。図５に示す例では、単位仕様文Ａ（蓋センサが 3sec以上 on の場合）がガ格パターンにマッチし、単位仕様文Ｂ（システムが機能する状態になる）がニ格・ガ格パターンにマッチするので、それぞれ変換している。
【００６４】
上述した図３では、格解析情報に基づいて生成した要求分析モデル要素が示されている。図３に示すように、図４に例示した各単位仕様文がデータフローダイヤグラム形式の要求分析モデル要素に変換されている。
【００６５】
生成した要求分析モデル要素にモダリティ情報と係り受け情報を付与し、記憶装置（図示しない）に保存する。
【００６６】
＜モダリティ情報による要求分析モデル要素の変換＞
生成された要求分析モデル要素をモダリティ情報（ここでは、モダリティ変換ルール）によって変換し、変換後要求分析モデル要素とする。変換ルールの決定には、要求分析モデル要素が持つモダリティ情報を利用する。モダリティ変換ルールは、ユーザが独自に設定可能であり、モダリティを複数適用する場合は適用する順序までルール化する。モダリティ変換ルールには、「逆接」、「条件」、「否定」等がある。「逆接」のモダリティ変換ルールは、排他的な出力フローを作成し、作成されたフローに無名のプロセスを接続するものである。「条件」のモダリティ変換ルールは、入力フローを出力フローとして接続し直すものである。「否定」のモダリティ変換ルールは、プロセスとそこに結合していた出力フロー、移行の要素を削除するものである。
【００６７】
図６は、モダリティ情報によって変換した要求分析モデル要素を示す図である。図６に示すように、単位仕様文１−１「蓋センサが 3 sec 以上 on となった」に対して、「条件」のモダリティ変換ルールを適用し、変換した要求分析モデル要素が生成されている。単位仕様文１−２については、付随したモダリティ情報がないので、元の要求分析モデル要素のままとなっている。
【００６８】
＜要求分析モデル構築＞
要求分析モデル構築処理は、（１）係り受け接続処理、（２）統合処理、に大別することができる。
【００６９】
（１）係り受け接続処理は、変換後の要求分析モデル要素に付随する係り受け情報を用いて選択した係り受け接続ルールにより、変換後の要求分析モデル要素をエッジ要素で接続して要求分析モデルを構築する。係り受け接続ルールは、ユーザが自由に定義することが可能である。例えば、
（ルール例１）：双方のノード要素を接続する。ただし、接続していないフローが存在する場合、新たなフローを作らずに、そのフローの接続先が内側を相手方に接続させる。
【００７０】
（ルール例２）：要素名を解析し接続の親和性が高い要素を接続する。
【００７１】
である。図７は、係り受け情報を用いた係り受け接続ルールによる要求分析モデル要素の接続例を示す図である。
【００７２】
（２）統合処理は、変換後の要求分析モデル要素の要素名が同じノード要素を同じものとして扱い、複数の変換後の要求分析モデル要素を統合する。図８は、変換後の要求分析モデル要素の統合を説明する図である。図８に示す例では、“蓋”で変換後の要求分析モデル要素を統合している。構築中の要求分析モデルは、統合の都度、記憶装置（図示しない）に記憶するのが好適である。
【００７３】
＜条件の不備の探索＞
以上のようにして、統合された要求分析モデル（以降では、単に要求分析モデルという）から、モダリティ情報を基にした要求仕様に含まれる条件の不備の探索について説明する。
【００７４】
図９は、要求仕様内の条件の不備を模式的に説明する図である。図９（ａ）は、模式的な仕様書を示している。図９（ｂ）は、模式的な要求分析モデルを示している。図９（ｃ）は、探索した要求仕様内の抜け漏れ条件の提示例を示している。
【００７５】
＜条件情報の作成＞
構築した要求分析モデルから、「条件」のモダリティ情報を持つノードまたはエッジを取得する。取得したノードまたはエッジが、特定パターンと一致するとき、要求分析モデルから“主体”、“状態”、“主節”、“仕様文への参照”の各値を取得する。ここで、特定パターンは、ユーザが任意に定義可能である。
【００７６】
図１０は、特定パターンを利用した“主体”、“状態”、“主節”、“仕様文への参照”の各値の取得を説明する図である。図１０（ａ）は、パターン例１による例、図１０（ｂ）は、パターン例２による例である。
【００７７】
（パターン例１）
ノードが「条件」のモダリティ情報を持ち、ノードがエッジを出力し、エッジにターゲットノードがあるパターンである。このパターンと一致する場合、各値は次のようになる。
【００７８】
主体：「条件」のモダリティ情報を持つノードの要素名
状態：ノードの出力エッジの要素名
主節：エッジのターゲットノードの要素名
仕様文への参照：「条件」のモダリティ情報を持つノードに付属する単位仕様文への参照から得た仕様文への参照
尚、「条件」のモダリティ情報を持つ要求分析モデル要素が、 主体と状態の両方を含まない場合もある。
【００７９】
（パターン例２）
ノードとエッジが「条件」のモダリティ情報を持っており、エッジにターゲットノードがあるパターンである。このパターンと一致する場合、各値は次のようになる。
【００８０】
主体：「条件」のモダリティ情報を持つノードの要素名
状態：「条件」のモダリティ情報を持つエッジの要素名
主節：エッジのターゲットノードから参照できる単位仕様文
仕様文への参照：「条件」のモダリティ情報を持つノードに付属する単位仕様文への参照から得た仕様文への参照
＜条件表への登録＞
取得した“主体”、“状態”、“仕様文への参照”の各値は、条件表に登録する。条件表は、条件を構成する“主体”と“状態”と、その“条件”が現れる“仕様文への参照”を行に持つ表である。図１１は、条件表の一例を示す図である。
【００８１】
＜仕様文-主節表への登録＞
取得した“主節”、“仕様文への参照”の各値は、仕様文-主節表に登録する。仕様文-主節表は、条件文が現れる“仕様文への参照”と、その仕様文が持つ“主節”を行に持つ表である。図１２は、仕様文-主節表の一例を示す図である。
【００８２】
図１３は、条件情報の作成処理の流れを示すフローチャートである。
【００８３】
まず、要求分析モデルからノードまたはエッジを一つ取得する（ステップＳ１３０１）。
【００８４】
次いで、取得したノードまたはエッジは「条件」のモダリティ情報に該当するか否かを判定する（ステップＳ１３０２）。
【００８５】
「条件」のモダリティ情報に該当しなければ（ステップＳ１３０２でＮｏ）、ステップＳ１３０１に戻り、「条件」のモダリティ情報に該当すれば（ステップＳ１３０２でＹｅｓ）、特定パターンを一つ取得する（ステップＳ１３０３）。
【００８６】
次に、「条件」のモダリティ情報が、特定パターンと一致するか否かを判定する（ステップＳ１３０４）。
【００８７】
「条件」のモダリティ情報が、特定パターンと一致するならば（ステップＳ１３０４でＹｅｓ）、パターンに対応する“主体”、“状態”、“主節”、“仕様文への参照”を要求分析モデルから取得する（ステップＳ１３０５）。
【００８８】
続いて、条件表に“主体”、“状態”が同値となる行があるか否かを判定する（ステップＳ１３０６）。条件表に同値となる行があれば（ステップＳ１３０６でＹｅｓ）、仕様文-主節表に、“仕様文への参照”、“主節”が同値となる行があるか否かを判定する（ステップＳ１３０７）。条件表に同値となる行がなければ（ステップＳ１３０６でＮｏ）、条件表に“主体”、“状態”、“仕様文への参照”を登録（ステップＳ１３０８）し、ステップＳ１３０７に移行する。
【００８９】
仕様文-主節表に、“仕様文への参照”、“主節”が同値となる行がなければ（ステップＳ１３０７でＮｏ）、仕様文-主節表に“主節”、“仕様文への参照”を登録（ステップＳ１３０９）した後、ステップＳ１３１１に移行する。仕様文-主節表に、“仕様文への参照”、“主節”が同値となる行があれば（ステップＳ１３０７でＹｅｓ）ステップＳ１３１１に移行する。
【００９０】
一方、「条件」のモダリティ情報が、特定パターンと一致しなければ（ステップＳ１３０４でＮｏ）、比較していないパターンがあるか否かを判定する（ステップＳ１３１０）。
【００９１】
比較していないパターンがあれば（ステップＳ１３１０でＹｅｓ）、ステップＳ１３０３に戻り、比較していないパターンがなければ（ステップＳ１３１０でＮｏ）、判定を行っていないノードまたはエッジがあるか否かを判定する（ステップＳ１３１１）。
【００９２】
判定を行っていないノードまたはエッジがあれば（ステップＳ１３１１でＹｅｓ）、ステップＳ１３０１に戻り、判定を行っていないノードまたはエッジがなければ（ステップＳ１３１１でＮｏ）、条件情報の作成処理を終了する。
【００９３】
＜複数条件表の作成＞
複数条件表は、複数条件となる“主体”集合と、複数条件となる“仕様文への参照”を列名とする表である。図１４は、複数条件表の一例を示す図である。図１４に示すように、“主体”の列には、“主体”が取り得る“状態”が入る。行は複数条件に現れる“状態”の組み合わせと、そのときの“仕様文への参照”を表す。例えば、複数条件表は、以下の手順で作成することができる。
【００９４】
（１）条件表から“主体”が取り得る“状態”集合を取得する。例えば、図１１に示す条件表から、A={T, F}、B={T,F}、H=｛T｝の“状態”集合が取得できる。
【００９５】
（２） 条件表で同じ“仕様文への参照”を持つ行から“主体”を取り出して“主体”集合とし、その“主体”集合を列名とする複数条件表を作成する。既に同じ“主体”集合を持つ複数条件表がある場合は作成しない。
【００９６】
（３）複数条件表の列名である“主体”が持つ“状態”集合を掛け合わせてできる全ての組み合わせを複数条件表に登録する。
【００９７】
（４） 条件表から“仕様文への参照”を複数条件表へ登録する。
【００９８】
図１１に示す条件表から、図１４（ａ）、図１４（ｂ）に示す複数条件表ができる。図１４（ａ）に示す複数条件表は、“仕様１”を持つ行から作成したもので、主体集合A,Bから成り、“仕様２”も主体集合A,Bを持つ。既に同じ主体集合から成る複数条件表が存在するので、新たには作成しない。図１４（ｂ）に示す複数条件表は、“仕様３”を持つ行から作成した複数条件表で、主体集合A,B,Hから成る。
【００９９】
＜統合複数条件表の作成＞
複数条件表の列名と等しい、または、内包する別の複数条件表があるとき、両表を用いた結合処理し、統合複数条件表とする。図１４に示す複数条件表において、X={A, B}、Y={A,B,H}とすると、列名の組X⊆列名の組Yであるから外部結合することができる。図１５は、統合複数条件表の一例を示す図である。
【０１００】
図１６は、統合複数条件表の作成処理の流れを示すフローチャートである。
【０１０１】
まず、条件表から行を一つ取得する（ステップＳ１６０１）。
【０１０２】
次に、取得した行の“主体”と同じ“主体”を持つ行を全て取得し、“状態”集合を得る（ステップＳ１６０２）。
【０１０３】
続いて、“主体”と“状態”集合を組として記憶装置に保存して登録する（ステップＳ１６０３）。
【０１０４】
次に、“状態”を登録していない“主体”があるか否かを判定する（ステップＳ１６０４）。
【０１０５】
状態を登録していない主体があれば（ステップＳ１６０４でＹｅｓ）、ステップＳ１６０１に戻る。一方，状態を登録していない主体がなければ（ステップＳ１６０４でＮｏ）、条件表から行を一つ取得する（ステップＳ１６０５）。
【０１０６】
続いて、“仕様文への参照”が同値の行を全て取得し、“主体”集合を得る（ステップＳ１６０６）。
【０１０７】
次に、“主体”集合を列名に持つ複数条件表があるか否かを判定する（ステップＳ１６０７）。
【０１０８】
複数条件表がなければ（ステップＳ１６０７でＮｏ）、“主体”集合を列名とする複数条件表を作成（ステップＳ１６０８）し、作成した複数条件表は記憶装置に保存する。
【０１０９】
その後、“主体”集合を掛け合わせてできる全ての“状態”を複数条件表に登録する（ステップＳ１６０９）。その後、ステップＳ１６１０に移行する。
【０１１０】
一方、複数条件表があれば（ステップＳ１６０７でＹｅｓ）、複数条件表へ“仕様文への参照”を登録する（ステップＳ１６１０）。
【０１１１】
次に、全ての行に対して行ったか否かを判定する（ステップＳ１６１１）。全ての行に対して行ってなければ（ステップＳ１６１１でＮｏ）、ステップＳ１６０５に戻る。全ての行に対して行ったならば（ステップＳ１６１１でＹｅｓ）、複数条件表の結合処理を行い（ステップＳ１６１２）、統合複数条件表は記憶装置に保存し、統合複数条件表の作成処理を終了する。
【０１１２】
＜条件の抜け漏れ情報作成＞
ここでは、仕様上に書かれていない条件を、抜け漏れ条件情報として作成し、抜け漏れ条件に続く“主節の候補”を登録する処理について説明する。係る処理は、概略、以下のステップで行う。図１７は、条件の抜け漏れ情報の作成を説明する図である。
【０１１３】
（１）統合複数条件表の中で、“仕様文への参照”を持たない行を未記述条件表に登録する。未記述条件表は、統合複数条件表の中で、“仕様文への参照”を持たない行を登録するもので、複数条件となる主体集合と、IDを列名とする表である。図１７（ｂ）は、図１７（ａ）に示す統合複数条件表から、“仕様文への参照”を持たない行を抜き出して登録した未記述条件表の一例を示す図である。図１７（ｂ）に示すように、“主体”の列には、“主体”が取り得る“状態”が入る。行は複数条件に現れる“状態”の組み合わせと、各行ごとに固有のIDが入る。
【０１１４】
（２）次に、 未記述条件表の各行ずつDon’t care以外の“状態”の値を取得し、“状態の組”とする。図１７（ｂ）に示す例では、５つの“状態の組”が取得されている。
【０１１５】
（３）次いで、取得した“状態の組”と同じ“状態の組”を持つ行、又は取得した“状態の組”に内包される“状態の組”を持つ行を統合複数条件表から探索する。例えば、図１７（ｂ）に示す未記述条件表でID=2を持つ行の“状態の組”で探索すると、図１７（ａ）に示す統合複数条件表の最下列で見つかる。
【０１１６】
（４）次に、探索した行が“仕様文への参照”を持つとき、その“仕様文への参照”と同値となる行を図１７（ｃ）に示す仕様文-主節表から探索する。図１７（ａ）に示す例では、統合複数条件表の最下列の“仕様文への参照”は、「仕様３」であり、図１７（ｃ）に示す仕様文-主節表から、最下列で見つかる。
【０１１７】
（５）次いで、探索した行が持つ“主節”と（２）で取得した未記述条件表の行が持つIDと対応付けて、主節候補データを登録する。“主節候補”は、未記述条件に続く”主節“になるか、または、未記述条件に続く”主節“と矛盾した関係ではない内容であることを示すものである。主節候補データは、未記述条件表の行ごとに割り当てられたIDと主節候補の集合を対応付けたデータである。図１７（ｃ）に示す例では、探索した行が持つ”主節“は「Ｅ」であり、ID=2である。同様にして、図１７に示す主節候補データが登録される。図１７（ｄ）に示す例では、主節候補として、「Ｅ」、「Ｃ」、「Ｄ」が登録されている。
【０１１８】
＜条件の抜け漏れ情報の提示＞
ここでは、抜け漏れ条件に続く“主節”の候補を元に、未記述条件表の全ての行をユーザへ提示する表示形式へ変換し、表示用データを生成する。表示用データを生成するとき、未記述条件表の行のIDと同じIDを持つ主節候補データからIDに対応付けられた“主節”を取得し、未記述条件の“主節候補”として利用する。図１８は、ユーザへの表示用データの一例を示す図である。
【０１１９】
図１９は、条件の抜け漏れ情報及び表示用データ作成処理の流れを示すフローチャートである。
【０１２０】
まず、統合複数条件表から複数条件表を一つ取得する（ステップＳ１９０１）。
【０１２１】
次に、取得した複数条件表から一行取得する（ステップＳ１９０２）。
【０１２２】
次に、取得した行が“仕様文への参照”を持たないか否かを判定する（ステップＳ１９０３）。
【０１２３】
次に、ステップＳ１９０３でＹｅｓであれば、続いて、取得した行を登録する未記述条件表が存在するか否かを判定する（ステップＳ１９０４）。
【０１２４】
取得した行を登録する未記述条件表が存在しなければ（ステップＳ１９０４でＮｏ）、続いて、取得した行を登録できる未記述条件表を作成（ステップＳ１９０５）し、作成した未記述条件表は記憶装置（図示しない）に保存した後、ステップＳ１９０６に移行する。
【０１２５】
一方、取得した行を登録する未記述条件表が存在すれば（ステップＳ１９０４でＹｅｓ）、取得した行を未記述条件表に登録する（ステップＳ１９０６）。
【０１２６】
次に、取得した行からDon’t care以外の“状態”の値を“状態の組”として取得する（ステップＳ１９０７）。
【０１２７】
続いて、“状態の組”に内包される行が複数条件表に存在するか否かを判定する（ステップＳ１９０８）。
【０１２８】
ステップＳ１９０８でＹｅｓであれば、続いて、“状態の組”が内包される行を複数条件表から取得する（ステップＳ１９０９）。
【０１２９】
次に、取得した行が“仕様文への参照”を持つか否かを判定する（ステップＳ１９１０）。
【０１３０】
取得した行が“仕様文への参照”を持つならば（ステップＳ１９１０でＹｅｓ）、同じ“仕様文への参照”を持つ行を仕様文-主節表から探索する（ステップＳ１９１１）。
【０１３１】
次に、“仕様文への参照”と主節候補を主節候補データへ登録（ステップＳ１９１２）し、ステップＳ１９０８に戻る。
【０１３２】
一方、取得した行が“仕様文への参照”を持たない（ステップＳ１９１０でＮｏ）のであれば、ステップＳ１９０８に戻る。
【０１３３】
ステップＳ１９０８で“状態の組”に内包される行が複数条件表に存在しなければ（ステップＳ１９０８でＮｏ）、判定を行っていない行があるか否かを判定する（ステップＳ１９１３）。
【０１３４】
判定を行っていない行があれば（ステップＳ１９１３でＹｅｓ）、ステップＳ１９０２に戻る。
【０１３５】
一方、判定を行っていない行がなければ（ステップＳ１９１３でＮｏ）、判定を行っていない統合複数条件表があるか否かを判定する（ステップＳ１９１４）。
【０１３６】
ステップＳ１９１４でＹｅｓであれば、ステップＳ１９０１に戻る。
【０１３７】
一方、判定を行っていない統合複数条件表がなければ（ステップＳ１９１４でＮｏ）、次に、未記述条件表から一行取得する（ステップＳ１９１５）。
【０１３８】
続いて、取得した行のIDと同じIDを持つ主節候補データを取得する（ステップＳ１９１６）。
【０１３９】
次に、表示用データを作成（ステップＳ１９１７）して、条件の抜け漏れ情報及び表示用データ作成処理を終了する。
【０１４０】
＜実施例＞
以上のように構成された自然言語記述検証装置１による一実施例について説明する。
【０１４１】
ここでは、以下の４つの仕様文を例としている。
【０１４２】
（仕様１）水温判定が偽であり、かつ、加温ボタンがOFFであれば、待機する。
【０１４３】
（仕様２）水温判定が偽であり、かつ、加温ボタンがONであり、かつ、給湯ロックがONであれば、加温する。
【０１４４】
（仕様３）水温判定が真であり、かつ、加温ボタンがOFFであり、かつ、給湯ロックがONであれば、保温する。
【０１４５】
（仕様４）水温判定が真であり、かつ、加温ボタンがONであり、かつ、給湯ロックがOFFであり、かつ、給湯ボタンがONであれば、保温する。
【０１４６】
要求分析モデル要素生成部１０において、上記仕様書の構文解析を行い、生成された単位仕様文から要求分析モデル要素を生成する。図２０は、要求分析モデル要素生成部１０で生成された要求分析モデル要素の一例を示している。
【０１４７】
次に、要求分析モデル構築部２０において、モダリティ情報から要求分析モデル要素を変換し、係り受け情報を用いて、変換後の要求分析モデル要素をつなぎ合わせて要求分析モデルを作成する。図２１は、要求分析モデル構築部において作成された要求分析モデルの一例を示している。要求分析モデル要素の単位でモダリティ情報を持っている。
【０１４８】
続いて、条件情報作成部３０において、統合要求分析モデルからモダリティ情報を基に条件を表す要求分析モデルのノードとエッジを取り出し、条件情報として、条件表及び仕様文−主節表を作成する。図２２は、統合要求分析モデルを元に作成された条件表及び仕様文−主節表の一例を示している。
【０１４９】
次に、複数条件情報作成部４０において、条件情報を用いて複数条件を持つ仕様文を見つけ、複数条件情報として複数条件表を作成する。作成された複数条件表は、結合処理され、統合複数条件表が作成される。図２３は、複数条件情報作成部において作成された複数条件表の一例を示している。図２４は、結合処理された統合複数条件表の一例を示している。
【０１５０】
続いて、条件の抜け漏れ情報作成部５０において、統合複数条件情報から仕様文への参照がない行を未記述条件表へ登録し、その登録した行ごとに主節の候補があれば、主節候補データが作成される。図２５は、作成された抜け漏れ条件情報の一例を示している。
【０１５１】
抜け漏れ条件情報である未記述条件表と主節候補データから、ユーザに抜け漏れ条件に続く主節の候補を提示する。ユーザへの提示には、未記述条件表と主節候補データそのものを提示してもよいが、よりユーザにわかりやすくするため、抜け漏れ条件に続く主節の候補を文形式で表示し、条件に続く主節として書かれるべき内容を提示するのが好適である。図２６は、抜け漏れ条件に続く主節の候補を文形式で表示した一例を示している。
【０１５２】
本実施形態によれば、要求仕様に含まれる条件を自動で見つけ出し、存在し得る条件を網羅的に探索して抜け漏れている条件節を提示する。また、現在の仕様と矛盾なく、抜け漏れている条件節に続く主節を書くための支援をする。これにより、要求仕様に含まれる不備の排除を促し、仕様の品質を向上させることができる。
【０１５３】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１５４】
１・・・自然言語記述検証装置
１０・・・要求分析モデル要素生成部
２０・・・要求分析モデル構築部
３０・・・条件情報作成部
４０・・・複数条件情報作成部
５０・・・条件の抜け漏れ情報作成部
【図１】
2015014827.tif 000003
【図２】
2015014827.tif 000004
【図３】
2015014827.tif 000005
【図４】
2015014827.tif 000006
【図５】
2015014827.tif 000007
【図６】
2015014827.tif 000008
【図７】
2015014827.tif 000009
【図８】
2015014827.tif 000010
【図９】
2015014827.tif 000011
【図１０】
2015014827.tif 000012
【図１１】
2015014827.tif 000013
【図１２】
2015014827.tif 000014
【図１３】
2015014827.tif 000015
【図１４】
2015014827.tif 000016
【図１５】
2015014827.tif 000017
【図１６】
2015014827.tif 000018
【図１７】
2015014827.tif 000019
【図１８】
2015014827.tif 000020
【図１９】
2015014827.tif 000021
【図２０】
2015014827.tif 000022
【図２１】
2015014827.tif 000023
【図２２】
2015014827.tif 000024
【図２３】
2015014827.tif 000025
【図２４】
2015014827.tif 000026
【図２５】
2015014827.tif 000027
【図２６】
2015014827.tif 000028