今回で、本連載も40回を迎える。足掛け4年ということになるから、長く続いたものだ。最近もある人から「良く書き続けることがありますね」と言われたが、まだまだ書くことがある。連載開始当初は「要求工学って何ですか?」と、IT業界の人からさえ聞かれることもあったが、最近は定着してきたように思うが、どうだろうか?
今回は、要求工学に関する最近の国際会議の内容から、どのような領域が研究されているか紹介したい。なお今回の内容の一部は「第2回要求シンポジウム」で講演したものである[1]。
要求工学の位置づけ
まず、要求工学を取り巻く環境を整理しておくと、図1のようになる。開発対象システム、要求を分析したり仕様化するためのモデル、下流工程の開発環境など、要求工学を取り巻く環境は継続的に変化している。
図1 要求工学の位置づけ
開発対象の変化としては、システムの大規模化と複雑化、組込みシステムの拡大、ビジネスとシステムの整合性、プライバシーや個人情報保護、内部統制などの法制度との整合性への配慮などがある。
モデリング技術の進歩には、UMLだけでなく、ゴール指向や非機能要求、ジャクソンの問題フレーム(第11回)、形式仕様などがある。
下流の開発環境の進歩には、WebやSOAなどのアーキテクチャの変化、パッケージやプロダクトラインなどの再利用を考慮した要求管理、アスペクト指向(第36回)などの新しい開発技術への対応などがある。
したがって、このような要求工学を取り巻く多種多様な変化を吸収して統合することにより、新たな要求工学手法を迅速に構築し、その有効性を評価した上で現場に導入するための適用技術の開発が必要となる。
要求工学の研究領域
REFSQ(International Working Conference on Requirements Enginee- ring:Foundation for Software Quality.)の分類に基づいて要求工学の研究領域を整理すると表1のようになる。
表1 要求工学の研究領域
REFSQでは、各論文の特性を明確にした上で、発表セッションの構成や各セッションで発表される論文間の相互関係が議論されるだけでなく、論文の読者は誰かということも明らかにすることが求められている。
◆論文形態
REFSQでは、要求工学の論文を現状技術の評価、経験評価、技術提案、技術評価に分類している。このような分類に従えば論文で述べられている知見の種類が分かるから、どのように活用すればいいかも知ることができるだろう。
◆プロセス
要求工学プロセスの構成要素には、要求抽出、モデリング、仕様化、要求分析、要求確認と要求管理がある。REFSQでは、論文がどのプロセスを扱うかを明確にすることが求められている。
◆アクタ
要求工学技術を活用する対象者としてのアクタとして、顧客、顧客の要求を分析する分析者、要求分析結果に基づいて要求仕様を作成する仕様作成者、要求仕様に基づいてシステムを開発する開発者、要求仕様に基づいてシステムを試験する試験担当者が考えられる。
◆技術
REFSQのキーワードとして挙げられている主要な技術には、以下のような技術がある。
・民族誌学
人間活動の中で利用されるシステムは、人間行動を観察する必要があることから、民族誌学などの文化人類学的なフィールドワークの手法を用いた現場観察が要求工学でも注目されるようになった。
・形式手法
システムの高信頼化が求められるようになったことから、形式手法が要求仕様書の記述や検査という観点から注目されている。
・モデリング
ゴール指向、問題フレーム、シナリオ、ユースケースなどのモデリング技術がUMLやビュウポイントとともに、継続して注目されている。
・インスペクション
本連載でも取り上げているように、要求仕様のレビュ技術や要求誤りの実証研究が必要である。
・自然言語処理
要求仕様書が自然言語で作成されること、顧客に理解可能な要求仕様は自然言語であることから、自然言語による仕様書の品質の検査や限定自然言語による仕様書記述などが研究されている。
・パターン化
要求工学を構成する生産物やプロセスをパターン化することで、生産物や作業の再利用を図ることで品質と効率を向上できる。
・プロセスモデル
要求工学を取り巻く環境の変化に伴い、要求工学プロセスの改善も必要となる。
・リスク分析
要求工学は見積もり技術と深い関係があるにもかかわらず、これまでは比較的独立に研究されてきた。しかし、パッケージや新技術の導入などでは、下流工程に入ってからリスクが顕在化する可能性が高いこともある。要求管理という点では、全開発工程に渡る活動が必要であり、この点で要求管理とリスク管理の統合が必要である。
◆生産物
REFSQでは、要求工学で扱う生産物として、ドメイン知識、形式仕様、試験仕様、アーキテクチャ、コード、ビジネスニーズ、顧客要求、開発要求を挙げている。
◆対象ドメイン
REFSQのキーワードにはないが、開発対象システムによって、必要な要求工学技術も変化する可能性がある。開発対象システムの変化には、SOC(Service Oriented Computing)、アスペクト指向、Web情報システムなどの基本的なアーキテクチャの変化、大規模化や組込みシステムや法制度への対応などシステム自体の変化、データウェアハウスやERPなどのパッケージやプロダクトラインによるシステムの再利用などの構成法の変化がある。
要求工学プロセスの現状
図2 要求工学プロセスのスパイラルモデル
Cheng[3]らによれば、要求工学プロセスについての統一的な体系はまだ確立されていないということであるが、図2に示すようなスパイラルモデルで要求工学プロセスの概要が示されることもある。要求工学プロセスの構成要素をREFSQ、Chengに基づいて整理すると以下のようになる。
◆要求抽出
要求抽出の生産物には、ゴール、アンチモデル、シナリオ、非機能要求などがある。ここでアンチモデルというのは、システムに対する攻撃的なアクタやミスユースケースなどのシステムにとって不都合な攻撃や脆弱性を明示的に表現して、それらからシステムを保護する要求をモデル化するための手法である。
要求抽出で用いられる技術には、インタビュ、民族誌学、発想法やシミュレーション、アニメーションなどがある。シミュレーションやアニメーションは要求確認でも用いられる。
◆モデリング・仕様化
モデリング・仕様化では、ドメインモデル、UML、形式仕様や限定自然言語が用いられる。モデリング・仕様化技術には、ビュウポイント、パターン化、モデル統合・モデル合成・モデルの再構成などがある。
◆要求分析
要求分析では、モデリング・仕様化と同様の生産物を扱う。要求分析技術としては、自然言語処理、オントロジーなどの自然言語としての仕様書を扱う技術と、顧客との交渉、要求の優先順位付けや要求選択などの合意形成に関するコミュニケーション技術、リスク管理や影響波及分析などのマネジメント技術などがある。合意形成やリスク分析、影響波及分析は要求管理と深い関係がある。
◆要求確認
要求確認では、検査証跡やチェックリストを記録管理する必要がある。要求確認技術としては、仕様のモデルに基づくシミュレーション、検査やアニメーションと、仕様書に対するレビュやインスペクションなどの品質検査手法がある。
◆要求管理
要求管理では、要求の属性情報だけでなく、要求の追跡性や変更記録を管理する必要がある。要求管理技術には依存関係の管理や意志決定支援手法がある。
要求工学技術の分類
要求工学技術を、プロセスとプロダクト、理論指向と現場指向という2つの視点から大きく分類すると、図3のように整理できると思われる。
図3 要求工学技術の分類
現場指向プロセス研究には、民族誌学などの現場観察、インスペクション、リスク分析などがある。
現場指向プロダクト研究には、自然言語処理、パターン化、シナリオ、ユースケースなどがある。
理論的プロダクト研究には、形式手法、問題フレーム、ゴール指向、UML、ビュウポイントなどがある。
理論的プロセス研究では、要求工学プロセスモデルを明らかにする。
それでは次に、この技術分類と開発対象システムという2つの観点から、ここ2年間のREFSQとRE国際会議の論文の特徴を調べてみよう。
最近の国際会議における注目領域
2006年と2007年に開催された要求工学に関する2つの国際会議(REFSQとRE)[4][5][6][7]の主要な論文65件について、研究対象と技術の観点から分析したところ表2のようになった。この表から採録論文件数の大きい部分をみると、以下のような傾向が分かるだろう。
・理論研究が約81.5%であり、現場指向の研究が遅れている。とくに理論的プロダクト研究が約55.4%で最も活発な研究が進んでいる。一方で、プロセスモデル研究も約26.2%ありやはり存在感がある。また、ゴール指向と非機能要求に関する研究は約35.4%、形式手法に関する研究も約10.8%あり、着実に進められている。現場観察についての研究が約9.2%であり、今後も期待される。
・対象システムを見ると、依然として約44.6%が従来型システムを対象としているが、新たなシステム変化に関する研究が約55.4%と逆転したことが分かる。とくに大規模化、組込み、法制度などの研究が26.1%となっていることがわかる。今後もこの傾向は続くと思われる。
・現場プロダクトの研究では、仕様書の自然言語処理についての研究がある。まだ少数だが価値指向の要求工学の研究が出始めている。いずれにしろ、現場で使える「要求仕様書の書き方」や実践的な要求レビュ手法などの研究開発が必要であろう。
ここで、国際会議の論文件数が示すデータについての考え方を注意しておく。ここで示されているのは採録された論文件数であって、件数が0だからといって研究が実施されていないことを示すわけではない。また件数が多いからといって、その分野の研究が成熟しているかどうかは分からない。成熟していないから活発な研究が実施されているかもしれない。また現場指向研究が少ないのは、研究者が現場の実態に触れる機会が少ないことや、現場のプラクティスを一般化する余裕が現場にないこともあるかもしれない。
要求工学の注目領域
以下ではChengらに従って、要求工学の注目領域を整理してみよう。
◆ゴール指向
要求変化を伴うシステムに適用するためのゴール指向要求工学手法を明らかにする必要がある。Rolland[8]らが提唱するゴール戦略マップでは、ゴールと手段間の依存関係を定義することによりゴールの動的変化を定義できる。
◆自然言語要求仕様
自然言語で記述された大規模な要求仕様を管理し、要求の曖昧さを解消するため要求の類似性の評価尺度や冗長な要求の管理、顧客要求に対する仕様の充足性などの課題を解決する必要がある。
◆曖昧要求
要求の曖昧さの原因として、仕様の不完全性、合意形成の不十分性、自然言語表現の曖昧性の3種がある。要求の曖昧さを解消するためには、自然言語記述の精度向上、状況情報の拡充、記述パターンなどの慣用表現の整備、要求レビュ、顧客の巻き込みが必要である。
◆意志決定支援
要求工学プロセスにおける情報の不完全性と不確実性を扱うために、要求工学における意志決定問題の定式化、確率論、統計、ベイズ推定、ファジー理論などの手法の適用法、戦略レベルの要求に関する意志決定法、意志決定プロセスの評価、非技術的意志決定課題(政治社会文化的側面)実証研究などが必要である。
◆ソフトウェア製品の要求工学
多数の顧客に対して提供されるソフトウェア製品開発のための要求工学手法(Market-Driven RE)を確立するために、プロセス品質、要求状態管理モデル、リリース計画など課題を解決する必要がある。
◆アジャイル要求工学
要求進化のための継続的顧客対話、優先順位付け、顧客価値順機能提供などのアジャイルプラクティスに適合する要求工学手法を確立する必要がある。
◆Webシステムの要求工学
Web情報システム(WBIS)開発では、関係者とその視点(ビュウポイント)によって定まる関心を要求に対応付けて管理する必要がある。
まとめ
今回は、要求シンポジウム[1]での講演内容に基づいて要求工学の現状と課題を、最近の国際会議の話題から紹介した。今後も、現場指向の要求工学手法が活発に研究開発されることを期待したい。
■参考文献
- [1] 第2回要求シンポジウム.https://sec.ipa.go.jp/seminar/2008/20080123.php
- [2] Aurum, A. and Wohlin, C. eds.“Engineering and Managing Software Requirements,”Springer, 2005
- [3] Cheng, B. and Atlee, J.,“Research Directions in Requirements Engineering,”Future of Software Engineering(FOSE'07), 2007
- [4] RE06,http://www.ifi.unizh.ch/req/events/RE06/index.html
- [5] RE07, http://www.re07.org/home/
- [6] REFSQ06, http://www.di.unipi.it/REFSQ06/
- [7] REFSQ07, http://www.info.fundp.ac.be/REFSQ07/
- [8] Rolland, C. and Salinesi, C., Modeling Goals and Reasoning with Them,
in [2]
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要