第 研究コース５（チーム年度ソフトウェア品質管理研究会第 研究コース（チーム .17）
KNT）


要求仕様の誤解釈を検出する Domain Word Modeling の提案
Proposal of “Domain Word Modeling”
to Detect Misinterpretation of Requirements Specification
柏原 一雄 （株式会社デンソークリエイト）
長井 亘  （テックスエンジソリューションズ株式会社）
谷口 侑太 （テックスエンジソリューションズ株式会社）

研究概要

仕様が自然言語のような曖昧さを含む記法で記述されている場合，仕様の誤解釈を誘発しやすい．実際に我々の組織では，「抽象的に表現された用語」を「不足している前提知識」で解釈することにより，誤解釈が発生していた．誤解釈の可能性のある用語を検出するために，用語の解釈を可視化する手法「'RPDLQ:RUG0RGHOLQJ」を考案した．
「'RPDLQ:RUG0RGHOLQJ」は，導入のしやすさを重視した手法である．実験で，実開発において定義された要求仕様を入力として，考案手法を実行し，効果を確認した．
 はじめに
ソフトウェア開発において，仕様は関係者の間の情報ハブ>@となり，仕様策定者は多数の関係者と仕様によりコミュニケーションをする．仕様が自然言語のような曖昧さを含む記法では他の人にわかるように表現することは難しく，用語の曖昧さや関連の曖昧さが，読み手の解釈を必要とし，異なる理解による問題を生じさせることが，文献>@で述べられている．
実際に我々の組織でも，要求仕様の誤解釈による手戻りが発生していた．誤解釈は，「抽象的に表現された用語」を「不足している前提知識」で解釈することにより発生していた．要求仕様のレビューは実施していても，このような用語の誤解釈を防止しきることはできていなかった．
本研究では，要求仕様の誤解釈による手戻りを減らすことを目的とし，誤解釈を誘発する可能性のある用語を検出するための手法を考案することを課題とする．考案手法は，導入障壁をできる限り低くし，コストやスケジュールの制約が厳しいプロジェクトでも効果を得やすくする．
考案手法は，要求仕様と前提知識を入力として，用語の関連を木構造で表現したモデルを作成する．考案手法は，導入障壁をできる限り低くするため，先行研究の「自然言語による仕様記述の改善のアプローチ」と「マインドマップモデリング」を参考にした．考案手法は，'RPDLQ:RUG
0RGHOLQJ と呼び，モデルの記述ルールとモデリングの手順を技術要素とする．
実験では，実開発において自然言語で記述された要求仕様を入力として，考案手法を実行し，考案手法が以下の要求を満たすかを評価した．
・ レビューで見逃した「誤解釈を誘発する用語」を検出できる
・ 要求仕様を自然言語で記述しているプロジェクトに対して導入しやすい
実験の結果，誤解釈を誘発する「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」を検出できることを確認した．また，実開発で使用されている要求仕様の形式を変更せずに手法が実行できること，'RPDLQ:RUG0RGHOLQJ 未経験でも手法の説明を受けただけで実行できることを確認した．
実開発において，'RPDLQ:RUG0RGHOLQJ を活用することで，要求仕様の誤解釈による手戻りを減らす効果が期待できる．
これ以降の本稿の構成は次のとおりである．章で現状分析の結果と研究の課題を示す． 章
では，課題解決の参考とした先行研究を示す． 章では，考案した解決策を提案する．章では，提案手法の評価結果と考察を示す．章では，まとめと今後の進め方を示す．


－1－

第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）
 課題設定
 現状分析
 要求仕様の誤解釈の要因
我々の組織では，要求仕様のレビューを実施していても，要求仕様の誤解釈が防止しきれず，手戻りが発生していた．要求仕様を誤解釈した事例を分析すると，「抽象的に表現された用語」を「不足している前提知識」で解釈していることにより発生していた．
特に，変更要求仕様を入力に，ベースソフトを部分的にしか理解できていない状況で，開発を行う派生開発>@では，このような誤解釈が発生しやすい．柏原>@は，派生開発において定義される変更要求仕様では，ベースソフトから変化しない既存仕様が抽象的に表現され，テストケースの漏れを誘発しているという調査結果を示している．また，ベースソフトを部分的にしか理解できていなければ，要求仕様を解釈するために必要な前提知識が不足している状態になりやすい．
 誤解釈を誘発する用語
我々の組織で，要求仕様の誤解釈を引き起こした事例を調査したところ，抽象的に表現された用語が誤解釈を誘発していることがわかった．
実際に誤解釈を誘発した用語の具体例を表 に示す．表 の用語を分類すると，「複数の種類がある概念」「複数の構成要素からなる概念」「対象によって具体的な行為が変わる概念」といった  つの種類に分けられる．どれも抽象的に表現された用語であり，種類・構成要素・対象を示す用語との関連がある．つまり，単独の用語ではなく用語間の関連が把握できていなかった．
表誤解釈を誘発した用語の例
用語
説明
ユーザ
○○ユーザ,△△ユーザなど，複数の種類がある．
支店
○○支店,△△支店など，複数の種類がある．
英語
米国英語英国英語豪州英語など，複数の種類がある．
原点
左上原点右下原点など，複数の種類がある．
改行&5/)/)&5 など，複数の種類がある．
診断情報'7&)UHH]HIUDPHGDWD などの構成要素から成る．
記憶
対象データや対象製品によって記憶場所が変わる．
開始
対象機能によって開始タイミングが変わる．
中止
対象機能によって中止処理が変わる（中止時に実施する処理が変わる）． 要求仕様のレビュー
要求仕様のレビューで，「抽象的に表現された用語」を問題として指摘することは難しい．また，要求仕様の読み手に「不足している前提知識」を明らかにすることも難しい．
レビューは，成果物や中間成果物を目視で確認し，問題がないか確認する行為である．
厳密な仕様>@を記述するときには，記述する仕様の抽象度と，記述の方法を決定する必要がある．最適な抽象度は，開発の目的や事情よって異なる．したがって，レビューで，抽象的に表現された用語を，一律に問題として指摘することはできない．
レビューでは，レビュー対象の成果物である要求仕様は確認されても，要求仕様を読むうえで必要となる前提知識は可視化されておらず，確認されにくい．したがって，レビューで，「不足>@している前提知識」を明らかにすることは難しい．小林 は，レビューで確認する情報の背景・前提を可視化する必要性を述べている． 課題提起
本研究では，要求仕様の誤解釈による手戻りを減らすことを目的とし，誤解釈を誘発する可能性のある用語を検出するための手法を考案することを課題とする．考案手法は，導入障壁をできる限り低くし，コストやスケジュールの制約が厳しいプロジェクトでも効果を得やすくする．


－2－

第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）

考案する手法は，以下の  つの要求を満たすものとする．
・ レビューで見逃した「誤解釈を誘発する用語」を検出できる
レビューでは防止できなかった誤解釈は，「抽象的に表現された用語」を「不足している前提知識」で解釈することにより発生していた．誤解釈を誘発する「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」を検出できる手法とする．
・ 要求仕様を自然言語で記述しているプロジェクトに対して導入しやすい
プロジェクトに新たな手法を導入しやすくするためには，「プロセスを変更するコスト」「手法を習得するコスト」「必要となるツールを用意するコスト」を下げる必要がある．「プロセスを変更するコスト」を下げるため，要求仕様の形式を変更せずに実行できる手法とす
る．要求仕様の形式を変更しなければ，要求仕様でやりとりをする関係者のコミュニケーションの仕方を変える必要がなくなる．
「手法を習得するコスト」を下げるため，考案手法を未経験の状態からでも，手法の説明を受けただけで実行できる手法とする．
「必要となるツールを用意するコスト」を下げるため，フリーソフトウェアで実行できる手法とする．

 先行研究 自然言語による仕様記述の改善のアプローチ
大森ら>@は，自然言語による仕様記述の品質向上を目的として，関係者の共通理解が得やすい自然言語記述と，厳密な検証に基づく安定したモデル化を可能とする形式モデルのそれぞれの長所を両立させるアプローチを提案している．図 のように，自然言語記述から形式モデルへ変換し，その形式モデル上で検証を行い，検証結果のフィードバックによる自然言語記述の改善を繰り返し行うというアプローチである．
要求仕様を自然言語で記述している開発プロセスに対して，要求仕様の形式を変更する必要がなく，導入
図要求の洗練プロセスしやすいアプローチである．
 シソーラス
用語の関連を表現するものとしてシソーラスがある．-,6;>@では，シソーラスにおける概念間関係が区別され，関係を表現するための略語が定義されている．
加藤ら>@>@は，シソーラスは，要求分析者のドメイン知識を補完し，要求の欠落を防止するために有用であることを示している．また，日本語で書かれた技術文書を入力に，形態素解析を活用し，シソーラスを構築する手法を提案している．
小川ら>@は，シソーラスを作成する行為が，関係者が相互の理解の相違を確認する手段となることが示している．
シソーラス及びその作成行為は，前提知識の不足を補う目的と前提知識の相違を明らかにする目的のために有用である．ただし，シソーラスを活用するためには，シソーラスの記法を学習する工数や記法からの逸脱を指摘・修正する工数が必要となる．
 マインドマップモデリング
マインドマップモデリング>@は，マインドマップを使って，自然言語からモデルを作成する手法である．自然言語から，80/ によるモデルを直接作成するのは難しいという考えから考案された手法である．マインドマップモデリングは，以下の手順で実施する．
 文章の中から名詞を抽出する 文章の中から動詞を抽出する 名詞の構造（LVD 関係，KDVD 関係）を定める
 692（名詞動詞名詞）で考える

－3－第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）

マインドマップモデリングは，木構造で用語をつなげるだけのシンプルな記法を使用しており，記法を学習するコストは，シソーラス等に比べると低い．マインドマップを作成するためのツールがあれば利用可能な手法であり，ツールにはフリーソフトウェアも存在する．

 解決策の提案 課題の解決方針
考案手法では，誤解釈を誘発する用語を検出するために，用語の解釈を可視化する．具体的には，要求仕様とそれを解釈するための前提知識を入力として，用語の関連を木構造で表現したモデルを作成する．これにより，「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」を検出することを可能とする．用語の関連を表現したモデルを確認することで，モデルを通して前提知識の相違を検出する．
要求仕様の形式を変更せず実行できる手法にするため，先行研究の「自然言語による仕様記述の改善のアプローチ」を参考とした．要求仕様の検証をするために，要求仕様のレビューに加えて，用語の関連を表現するモデルの作成と作成したモデルのレビューをする．仕様策定者と「プロジェクトの外部」「プロジェクトの次工程」の担当者とのコミュニケーションは，手法導入前と変わらず，自然言語で記述された要求仕様を使用して行う．
更に，可能な限り小さい導入コストで実行できる手法とするため，用語の関連を表現するモデルは，「マインドマップモデリング」を参考に，可能な限りシンプルな記法とする．マインドマッ
プモデリングで作成されるモデルは，概念と概念間のつながりを木構造で示すだけのシンプルなものであるが，LVD 関係と KDVD 関係を表現し，「抽象的に表現されている用語」を特定することは可能である．また，マインドマップはフリーソフトウェアで作成することが可能である．マ
インドマップをベースとした手法とすることで，手法を習得のためのコスト，手法の実行に必要となるツールを用意するコストの両方を小さくする．
考案手法は，'RPDLQ:RUG0RGHOLQJ（':0RGHOLQJ）と呼び，手法により作成された用語の関連を表現したモデルを 'RPDLQ:RUG0RGHO（':0RGHO）と呼ぶ．図 に，':0RGHOLQJ の概要を示す．考案手法は，':0RGHO の記述ルールと ':0RGHOLQJ の手順を技術要素とする．


図':0RGHOLQJ の概要 ドメイン用語の定義
':0RGHOLQJ では，開発対象のシステムを定義するために必要となる用語を，ドメイン用語（'RPDLQ:RUG）と呼ぶ．ドメイン用語は，サ変名詞を含む名詞を対象とする．
 'RPDLQ:RUG0RGHO の記述ルール
':0RGHO の記述ルールを以下に定義する．
・ 同義語が存在しない状態にする．同義語は  種類のみ登場させる．
・ 各階層には，集約（$KDVD%）と汎化（$LVD%）の関係を混在させない．
・ 必要に応じて要求仕様で使用されていない用語をモデルに登場させてよい．
・ 末端の枝にのみ，名詞ではなく，文・式・値等を示してもよい．
図 に，':0RGHO のイメージを示す．これは，テスト設計コンテスト’ の $67(5 自動販売機ユースケース仕様書を入力に作成したものである．
－4－第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）

図':0RGHO のイメージ 'RPDLQ:RUG0RGHOLQJ の手順':0RGHOLQJ は，「形態素解析」，「モデリング」，「モデルのレビュー」の  ステップで，要求仕様で使用されている用語の解釈を可視化する．形態素解析を利用し，ドメイン用語を漏れなく効率的に抽出する．モデリングでは，抽象的な用語に対して下位概念となる用語を抽出し関連付け，用語の解釈を可視化する．モデルのレビューでは，「0(&( であるか」を確認する．
':0RGHOLQJ の手順を以下に定義する．
 形態素解析
要求仕様を入力に，形態素解析を行い，要求仕様で使用されている単語を抽出する．複合語として正しく抽出できていない単語や未知語と判断される単語がある場合には，ドメイン用語と判断すべき単語を形態素解析で使用する辞書に追加し，形態素解析を再実施する．
 モデリング
形態素解析で抽出した単語から，要求仕様で使用されているドメイン用語を特定する．':
0RGHO の記述ルールに従い，特定したドメイン用語を木構造で関連付ける．抽象的な用語に対して下位概念となる用語を抽出し関連付けをするために，必要に応じて入力としている要求仕様以外の技術文書等も参照する．
 モデルのレビュー
木構造で表現されたモデルの各階層が 0(&( な状態にするために，':0RGHO の記述ルールを満たしているか確認する．不足している前提知識があれば，入力とした要求仕様以外の技術文書等から必要な情報を得て，モデリングを再実施する．

 解決策の評価
 評価方法
考案手法が以下の  つの条件を満たすか確認し，考案手法の有効性と導入容易性を評価する．
$ 「抽象的に表現されている曖昧な用語」を検出できる
抽象的に表現されていることが要因で誤解釈を誘発する可能性のある曖昧な用語を，モデリング実施者が検出できたかを確認する．
% 「解釈のための前提知識が不足している用語」を検出できる
モデリング実施者の前提知識の不足が要因で誤解釈を誘発する可能性のある用語を，モデリング実施者またはモデルのレビューアが検出できたかを確認する．
& 要求仕様の形式に依存せず実行できる
複数の異なる形式の要求仕様を入力に ':0RGHOLQJ を実行し，':0RGHO が作成できることを確認する．


－5－

第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）
' ':0RGHOLQJ が未経験の状態からでも実行できる
':0RGHOLQJ が未経験の状態から，手法の説明を受けるだけで，':0RGHO が作成できることを確認する．更に，モデリング中に，手法に関する質問が発生しないことを確認する．
実験は，以下の条件下で実施し，評価のために表 に示すデータを計測する．
・ 入力とする要求仕様は，実開発で使用されている文書で定義されているものとする．
・ 入力とする要求仕様は，レビューが完了している状態とする．
・ モデリング実施者は，':0RGHOLQJ 未経験者とする．
・ モデリング実施者は，':0RGHO の記述ルールと ':0RGHOLQJ の説明を受ける．
・ モデリング実施者は，要求仕様に記載されている用語を知っている．
・ 形態素解析は，.+&RGHU>@を使用して実施する．
・ モデリングは，マインドマップ作成が可能なフリーソフトウェアを使用して実施する．
表計測データの種類
データ
説明
用語数
要求仕様
要求仕様に登場する名詞の数．.+&RGHU で抽出された名詞の数．出現回数ではない．
':
要 求 仕 様 ':0RGHO に登場する用語の中で，要求仕様に存在し0RGHO にありている用語の数．
要 求 仕 様 ':0RGHO に登場する用語の中で，要求仕様に存在しになしていない，モデリング実施者が追加した用語の数．
誤解釈の可能性 
要求仕様から検出した，誤解釈を誘発する可能性ののある用語数
ある用語の数．
表現の要因
抽象的に表現されている曖昧な用語の数．
知識の要因
解釈のための前提知識が不足している用語の数．
手法への質問の数
モデリング中に発生した，手法に対する質問の数．
 評価結果
実験の結果を表 に示す．被験者～ は同じ要求仕様を入力とした．被験者 は自分自身が書き手である要求仕様を入力とした．被験者 以外は他者が書き手である要求仕様を入力とした．
表実験の結果
被験者 要求 立場
用語数
誤解釈の可能性 手法への,'
仕様のある用語数
質問の数
,'
要求仕様 ':0RGHO
表現の 知識の要因
要 求 仕 様 要 求 仕 様 要因にありになし$ 書き手





$ 読み手
$ 読み手

$ 読み手% 読み手& 読み手
実験の結果から，':0RGHOLQJ が．評価方法に示した  つの条件を全て満たすことが確認できた．確認結果を以下に示す．
・ 全ての被験者が，「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」のどちらかを検出できた．
「解釈のための前提知識が不足している用語」の検出数が少ない場合，つまりモデリング実施者が要求仕様の理解度が高い場合，「抽象的に表現されている曖昧な用語」を検出できる傾向があった．また，一部の誤解釈を誘発する可能性のある用語は，モデルのレビューの前に，モデリングをしながら検出された．


－6－

第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）

・ 形式が異なる複数の要求仕様を入力として，':0RGHO を作成できた．要求仕様$ は，派生開発で作成された変更要求仕様書であり，仕様の変化点のみが記述されている．モデルを0(&( な状態にするため，':0RGHO に，入力とした文書にない用語が多く追加された．
・ ':0RGHOLQJ が未経験の状態でも，一通りの説明を受けるだけで，全ての被験者が ':0RGHOを作成できた，また，モデリング中に手法に対する質問もなかった．
 結果の考察
':0RGHOLQJ は，レビューでは見逃した「誤解釈を誘発する用語」を検出できる有効な手法である．用語の関連を木構造で表現したモデルを作成する行為を通して，「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」を検出し，「わかったつもり」>@の状態に気づくことができる．モデリング実施者にとって解釈が難しい用語は，モデルに表現することも難しい．用語の関係を 0(&( に表現しようとすることで，誤解釈する可能性のある用語を，自分自身で検出することができる．また，用語の解釈が可視化されることで，関係者間で解釈の比較することが可能となり，誤解釈する可能性のある用語を検出することができる．
':0RGHOLQJ は，要求仕様を自然言語で記述している開発プロセスに対して導入しやすい手軽の手法である．要求仕様の形式を変更しなくても実行できる手法であるため，要求仕様を情報ハブとしたコミュニケーションの仕方を変える必要もない．また，木構造で用語をつなげるだけのシンプルな記法であるため，':0RGHOLQJ が未経験の状態でも，一通りの説明を受けるだけで実行できる．
':0RGHOLQJ を実行する工数を小さくし，更に手法を導入しやすくするためには，以下の対策が有効であることが，実験の結果からわかった．
・ 小さく繰り返す
':0RGHOLQJ は，要求仕様書の全体ではなく，一部の記述に対しても，実行可能である．
例えば，変更要求仕様書に定義されている一件の変更要求に対しても実行可能である．開発期間が限られている場合でも，':0RGHOLQJ の対象とする記述を絞り込むことで，現実的に投入可能な工数で実行可能となる．更に，作成されたドメイン用語のリストと ':0RGHOは再利用可能であり，手法を繰り返し実行する度に，必要となる工数は低減される．
・ 書き手が実行する
':0RGHOLQJ は，要求仕様の書き手が実行しても，自分自身で定義した要求仕様に対して「誤解釈を誘発する用語」を検出することが可能である．書き手が自分自身で，「わかったつもり」の状態に気づくことができる．要求仕様の書き手であれば，解釈が難しい用語は少ないため，短時間でモデリングができる．効率的に仕様記述の改善をするためには，':
0RGHOLQJ を要求仕様の書き手が実行したほうがよい．
・ 入力文書の質を高めたうえで実行する
要求仕様書内に，対象とするシステムを定義するためには不要である用語が多く存在する
場合に，ドメイン用語を特定する作業の効率は悪くなる．例えば，同義語，誤記が多い文
書，例が示されている箇所が特定しにくい文書，主語が異なる記述（例サーバーとクライ
アント，システムとサブシステム）が混在している文書，仕様と設計の位置づけの記述が混在している文書などである．':0RGHOLQJ をする前に，入力とする要求仕様の記述をモデリングがしやすいように改善する取り組みをすると，効率が向上する可能性がある．
 おわりに
用語の曖昧さや用語間の関連の曖昧さは，読み手の前提知識をもとにした解釈を必要とし，要求仕様の誤解釈による手戻りにつながる可能性がある．実際に，自然言語で要求仕様を記述しているプロジェクトにおいて，抽象的に表現されている用語が，要求仕様の誤解釈を誘発していた．
本研究では，要求仕様の誤解釈による手戻りを減らすことを目的とし，':0RGHOLQJ を考案した．実験で，':0RGHOLQJ は，以下の要求を満たす手法であることが確認できた．


－7－

第  年度ソフトウェア品質管理研究会第  研究コース（チーム .17）
・ レビューで見逃した「誤解釈を誘発する用語」を検出できる
・ 要求仕様を自然言語で記述しているプロジェクトに対して導入しやすい':0RGHOLQJ は，「わかったつもり」の状態を抜け出すための有効かつ手軽な手法である．「小さく繰り返す」「書き手が実行する」「入力文書の質を高めたうえで実行する」という工夫をすることで，':0RGHOLQJ の効率を上げることができる．
':0RGHOLQJ は，実開発においてもスムーズに導入でき，要求仕様のレビューに加えて実行されることで，要求仕様の誤解釈による手戻りを減らす効果を生み出すことが期待できる．
今後は，':0RGHOLQJ の有効性と効率性を更に高めるために，以下の取り組みを行う．
・ 実開発で ':0RGHOLQJ を継続的に活用し，その結果をもとに，':0RGHO の記述ルールと ':
0RGHOLQJ の手順を改善する．
・ ドメイン用語を漏れなく誤りなく効率的に抽出するために，自然言語処理技術を活用し，複合語と未知語を適切に抽出する方法を検討する．
・ 開発全体を効率化するため，要求仕様を参照する次工程でも ':0RGHO を活用することを検討する．
例えば，':0RGHO をテスト観点ツリー>@のベースとして活用することを検討する．
・ 86'0>@，656 記述ガイド>@，文書校正支援ツールなどを活用し，入力とする文書の質を高めておくことで，':0RGHOLQJ の効率が上がることを確認する．

謝辞
本研究に対して有益なご助言をいただいたソニー株式会社栗田太郎氏，国立情報学研究所石川冬樹氏，熊本高等専門学校荒木啓二郎氏，南山大学張漢明氏，第  年度ソフトウェア品質管理研究会第  研究コースのメンバに感謝の意を表する．
本研究の実験にご協力いただいた株式会社デンソークリエイトとテックスエンジソリューシ
ョンズ株式会社のプロジェクトメンバに感謝の意を表する．

参考文献
>@厳密な仕様記述ＷＧ委員，「厳密な仕様記述入門」，独立行政法人情報処理推進機構，
>@清水吉男，「「派生開発」を成功させるプロセス改善の技術と極意」，技術評論社，
>@柏原一雄，「派生開発におけるテスト漏れを防止する 'LIIHUHQFH6WDWHPHQW&RYHUDJH 分析法の提案」，ソフトウェア品質シンポジウム ，
>@小林展英，「'&DVH を用いたレビューを見える化する方法の導入事例」，WK:RUNVKRSRQ&ULWLFDO6RIWZDUH6\VWHP，
>@大森洋一，荒木啓二郎，「自然言語による仕様記述の形式モデルへの変換を利用した品質向上に向けて」，情報処理学会誌プログラミング9RO1R，
>@「-,6;シソーラスの構成及びその作成方法」，日本工業規格，
>@加藤潤三，佐伯元司，大西淳，海谷治彦，山本修一郎，「シソーラスを利用した要求獲得方法（7+(25((）
」，情報処理学会論文誌1R1R，
>@加藤潤三，佐伯元司，大西淳，海谷治彦，林晋平，山本修一郎，「要求獲得のためのシソーラス構築支援」，情報処理学会論文誌1R1R，
>@小川清，斉藤直希，吉川直邦，「リアルタイム組み込みソフトウェアの用語の木」，電子情報通信学会技術研究報告コンピュータシステム  ，
>@浅海智晴，「マインドマップではじめるモデリング講座」，翔泳社，
>@樋口耕一，.+&RGHU，KWWSNKFVRXUFHIRUJHQHW，
>@西林克彦，「わかったつもり読解力がつかない本当の原因」，光文社新書，
>@羽田裕，青木教之，「テスト視点による上流工程での予防活動と検知活動の成熟度向上」，組込みソフトウェアシンポジウム ，
>@不破慎之介山田ひかり，蛸島昭之，「要求記述のスキル不足に対する656記述ガイドの有効性評価」，ソフトウェア・シンポジウム ，

－8－