要求工学プロセスは，ソフトウェア開発における最初の重要なプロセスである．このプロセスを通してソフトウェアへの要求が定義され，その目的と機能が定義される．その後の開発は，ここで作成された仕様に基づいて遂行される．要求工学は，ソフトウェアそのものの意味論を扱う唯一の技術であるとさえ言える．

　ソフトウェアの意味を定義するために，要求工学は，情報システムへの要求元である複雑で曖昧な現実世界と，要求された機能を実装する厳密で正確なソフトウェアという2つの異なった世界を，その作業対象としなければならない．要求技術者は，要求者との共同作業を通して，ソフトウェアが備えるべき要件を明確にし，それを設計するのに必要かつ十分な情報を収集しなければならない．決められた期間内に，問題領域の知識やソフトウェアへの要求を正確に理解するだけでなく，要求者が欲している本質的な要求を見抜き，あいまいな要求を明瞭にし，矛盾した要求を調整する必要がある．

　要求プロジェクトが抱えるこうした問題を解決するために，様々な手法や方法論が開発されてきた．しかし，個々のプロジェクトが置かれた状況は多様であり，熟練した要求分析者たちの知識が，相変わらずプロジェクト成否の鍵を握っているという状況に変わりはない．こうした熟練分析者のノウハウを，一般の技術者が再利用できるようにするには，それらを明示化し，多くの技術者が理解可能な形で表現する必要がある．様々な要求工学技術を利用して問題を解決するための，発見的知識の再利用が，要求工学のもう1つの課題である．

　本研究の主題は，要求工学プロセスにおける発見的知識を体系化し，それらの表現法を検討することである．知識には，個別の知識と体系化された知識がある．個別の知識は，その中から普遍的な知識を選別することによって再利用が可能となる．普遍化は，発見的な知識に対して，有効な手段である．しかし，それらの知識は，普遍性を持ってはいても，依然として個別のままである．関連した多くの知識が収集されると，知識の効率性を目指した抽象化が始まり，知識体系が整備される．しかし，抽象化された知識からは，詳細な情報が捨象されてしまうおそれがある．それぞれの知識の特性に応じた適切な体系化が必要である．

　知識は，その性質によって表現の方法も異なる．知識を規則によって表現する方法は，メタ知識や発見的知識を表現するのに適しており，機械化も可能である．一方，自然言語による表現は，冗長性がある反面，文脈や構文といった付加的な機構による豊富な意味世界の表現が可能であり，普遍化された知識を表現するのに適している．絵や図式を使った表現は理解の容易性に優れているが，表現できる情報量に限界があり，補完的な手段が必要となる．本研究では，プロジェクトにおける問題解決と，要求獲得手法の選択，および，要求モデルの変更という3種類の知識の体系化と表現法について述べる．

　様々な技術が開発されてきたにも関わらず，ソフトウェア開発の失敗の原因の多くが，要求プロセスにあると言われている．こうした指摘をもとに，第1章では，要求工学の現状を技術的な側面から概括し，それをもとに，多様な要求工学技術を活用するための経験則の重要性について述べる．しかし，経験に基づく発見的知識は定形的な形式を持たないため，それらを再利用するには，それぞれの知識を記述するための独自のフレームワークを必要とする．

　異なった知識と経験を持った人たちが共同で作業を行う要求プロジェクトでは，さまざまな問題が発生する．第2章では，それらを解決するために，熟練技術者の持つ発見的な知識を記述するための，基本的なフレームワークについて述べる．

　発見的知識を記述する枠組みとして，パターン技術が用いられることが多い．パターンでは，経験則を含むあらゆる知識が利用者に公開されており，要求技術者の個別の知識と，コンピュータ内の専門的な知識の融合によって，問題解決を図ることが可能である．パターンは，通常，問題と解の組み合わせによって構成される．しかし，様々な原因が複雑に絡み合う要求工学プロセスでは，同じ問題に対し，何時も同じ解が適用できるとは限らない．要求技術者が，多くのパターンの中から，そのプロジェクトに適したパターンを選択できるようにするには，既存のパターン形式が持つ情報に加えて，さらなる情報が必要となる．

　本章では，具体的な事例の構造解析を通して，一般的なプロセスパターンを，状況セクションと課題セクションに拡張する．状況セクションは，状況変化の中でプロジェクトの位置を定義するための，また，課題セクションは，プロジェクトが抱える具体的な問題とそれに対する解法について記述するための，フレームワークである．図-1に状況セクション，図-2に課題セクションの構造を示す．

　プロジェクトに問題が発生すると，その状況は様々に変化して行く．要求技術者が，適切なパターンを効果的に発見するには，プロジェクトの状況遷移に関する知識が必要である．要求技術者が，プロジェクトの状況を，プロセスの流れの中で理解するための状況遷移図を提案する.状況遷移図の中で，プロセスは作業ステージによって表現され，各ステージの中で状況変化が発生する．図-3に状況遷移図の例を示す．

　第3章と第4章では，上で述べた要求工学プロセスパターンに記述される，具体的な知識について述べる．

問題の多様性に合わせて，様々な技法が提唱されてきた．これは，プロジェクトに適した要求工学技法を選択するにはどうすれば良いか，という新たな問題を提起する．第3章では，プロジェクトの特性をもとに，適切な技法選択の基盤となるフレームワークについて述べる．

　プロジェクトは，対象問題領域や，システムのタイプ，大きさ，組織の文化といった様々な要因によって特徴付けられる．プロジェクトの特性に合わない要求工学手法が選択されると，そのプロジェクトは障害に陥ってしまうかもしれない．要求手法とプロジェクトの特徴を関係付ける汎用的なフレームワークが必要とされる．さらに，プロジェクトの状況変化にどのように寄与できるかということも，要求工学手法を適用する上でのもう一つの課題である．障害プロジェクトは，直面している問題を解決するために，要求工学手法を選択し，適用しなければならない．

　本章では，代表的な要求工学技法を，適用領域の特性と問題の処理方法によって4つのグループに分類し，要求工学技法マップという座標空間に配置する．このマップによって，数ある技法を個別に習得しなければならないという労力から要求技術者を解放し，適切な技法の選択を容易にする．図-4に要求工学技法マップを示す．ここで，閉じている/開いているという軸は問題領域の特性，静的/動的という軸は処理方法を示している．要求工学技法マップを使用して適切な手法を選択するために，アプリケーションドメインの特性，要求技術者のタイプ，入手可能な情報資源の量，ユーザ参加の有無，求められる要求品質と非機能要求という6つの判定基準を提案し，さらに，プロジェクトの状況変化に対応するために，プロジェクトの状況と要求工学技法マップとの対応についても言及する．

　要求プロジェクトにとって，もう1つの大きな問題は，要求変更が発生したときの対応である．第4章では，要求変更が発生したときに，異なった要求モデルの間の一貫性を保証するための知識について述べる．

　獲得されたシステムへの要求や問題領域の知識は，モデルや要求仕様として記述され，作成すべきシステムの要件が定義される．しかし，要求者や技術者はそれぞれ独自の観点を持っており，こうした観点の違いをもとに，問題領域を多面的に表現するために，異なった要求モデルが作成されることになる．しかし，システムとしての統一性を保つには，異なった要求モデルの間での意味と形式の一貫性が保証されなければならない．

　本章では，モデル変更実験で得られた知見をもとに，要求変更が発生したときに，異なった要求モデル間で変更箇所を特定するためのモデル連携と，モデルの部分的変更に伴う2次的な影響箇所を特定するための影響追跡という，2種類の一貫性保証のための知識と仕組みについて述べる．

　図-5にUMLによる要求モデル間のモデル連携依存関係を示す．

　モデル連携では，モデル間の連携である《model-trace》と，モデル要素間の連携である《element-trace》という2種類の依存関係によって連携を表現する．また，技術者による依存関係設定作業を支援するために，基本的な制約条件を規則の形で表現する．一方，影響追跡関係は極めて複雑で，それらのすべてをモデル作成時に指定させることは現実的ではない．そのため，基本的な制約関係を規則の形で表現する．図-6は，クラス図における影響追跡規則の一部である．

　最後に第5章で，全体のまとめを行い，今後の課題として，多様な形式で記述された知識を，実際のプロジェクトに供するための支援ツールについて言及する．

　支援ツールは，上記3章で述べたような知識ベースを持ち，個別のプロジェクトモデルを作成することによって利用者の問題を特定し，解を導き出す．それぞれの知識に固有の図や座標，あるいはテキストを使った表現は，知識表現ベースとして使用可能となっている．図-7に支援ツールの構造を示す．

図-1　状況セクションの構造

図-2　課題セクションの構造

図-3　状況遷移図

図-4　要求工学技法マップ

図-5　モデル連携関係

図-6　影響追跡規則の一部

図-7　支援ツールの構造

　情報システムを開発するプロセスは，そのシステムの持つべき機能や性質に関する要求を収集，分析し，明確に定義する作業から始められる．要求記述が曖昧であったり不十分であると，それに基づいて開発された最終プロダクトの品質は保証されない．このようにシステムに対する要求を抽出し明確化する過程を，ここでは要求工学プロセスと呼んでいる．

　要求を明確化するためには，対象とする問題領域に関する知識，システム利用者の持つ知識，要求工学の多様な手法に関する知識，などさまざまな知識を活用する必要がある．本研究は，要求工学プロセスにおいて生じる問題を解決するために必要な知識の，表現方法の工夫とその体系化を探求したものである．その結果は，要求工学を実施するための知識のフレームワークという形で提案されている．このフレームワークは，次の3種類の知識系で構成される．

　・プロジェクトにおける個別の問題解決のための知識

　・プロジェクトに適した要求獲得技法の選択に関する知識

　・要求変更におけるモデルの一貫性保障に関する知識

　本論文は5章で構成されている．

　第1章ではまず，現在の情報システムに課せられた要求工学上の課題を提示する．そしてそれらの課題に対処する要求工学技術の現状を広く調査し，整理して記述している．この部分は独立したサーベイとしても有用な資料として読めるものになっている．さらに，それらの課題と技術の現状に対して，本研究で提案する方法が，どのような点に着目し，どのように位置づけられるものであるかを示している．

　第2章では，個々の開発プロジェクトにおいて要求工学プロセスを進める際に，偶発的に生じうるさまざまな問題に対し，どのようにそれを解決すればよいか，という知識を扱う．それらの知識は多分に発見的性質を有し，その表現方法と体系化には工夫が必要である．この章では表現方法として，「プロセスパターン」を提案している．プロセスパターンは「状況」に関する部分と「課題」に関する部分とに区分され，さらに各々が形式化された構造を持つ．具体的なプロジェクトにおける要求工学プロセスにおいて，現時点の「状況」に照合したパターンが選択され，その「課題」部分を特定化し適用することで，問題解決が図られる．提案された方法の適用例は，実際のプロジェクトに即して説明されている．その成果は，著者の長年のシステム開発経験に基づいているところに，大きな特徴と意義がある．

　要求工学分野ではすでにさまざまな技法が蓄積されている．第3章では，それらの技法の中から，対象となるプロジェクトに適切なものをどう選択するか，という知識が扱われる．プロジェクトは，取り扱う問題領域，システムの形態，システムの規模，利用者の特性，開発チームの技術や経験レベル，組織文化，などさまざま要因により特徴づけられる．一方，適用可能な技法はおびただしく存在するが，技法を説明する教科書，マニュアルの類を見ても，当面のプロジェクトへの適合性は判断しかねる場合が多い．この章では，多くの技法を2つの主要軸で分類した上で，プロジェクトの特性に応じた選択の指針を，さまざまな角度から論じている．この内容は国際会議で発表されて高く評価され，それをさらに詳細化した論文が定評ある学術誌に採録され掲載されているが，それだけの独自性があるものと認められる．

　第4章では，要求工学プロセスの結果として構築される要求モデルの連携の問題が対象となる．とくに要求が変更される場合に，対応するモデルの一貫性をいかに保つかという知識が取り扱われる．要求は一般に複数のモデルによって記述されることが普通であり，したがって変更に対する一貫性としては，1つのモデル記述内の整合性だけでなく，モデル間の連携に関する整合性の保持が重要な課題となる．この章ではモデル間の連携を規則として記述する方式を提案し，要求変更に対してそれらの規則を適用して一貫性を保証する仕組みを与えている．また，その手法は，金融向けソフトウェアを対象にした事例研究により評価されている．

　第5章では，全体のまとめと今後の課題が述べられている．

　このように，本研究は著者の豊富なソフトウェア開発経験と，要求工学分野における研究成果の幅広い調査に基づき，独自の知識フレームワークを提案した点に，大きな学術的貢献があると認められる．

　よって，本論文は博士(学術)の学位論文として相応しいものであると審査委員会は認め，合格と判定する．