|
|
概 要 今回は第12回の要求工学国際会議（International Conference on Requirements Engineering, ICRE）の主要な話題を紹介しよう。 RE2004は日本の京都で９月６日から11日まで立命館大学の衣笠キャンパスで開催された[1]（図１）。26カ国から約200人が参加した。22件の技術論文と５件の事例研究、11件の産業界からの報告があった。筆者は産業報告「要求プロセスとツールの選択と管理」セッションとチュートリアル「シナリオ分析」の座長と要求追跡のチュートリアルを担当した。主要なスポンサーには弊社のほか、Borland やMicrosoft、ダイムラークライスラーなどがあった（図２）。 主な論文の採録国を見ると、英国、米国、ドイツが多く、日本からの技術論文は１件だった。ドイツでは、ダイムラークライスラーからの経験論文が３件提出されており、存在感があった。自動車のソフトウェア化が進展しており、組み込みソフトの要求工学が重要になってきたといえる。同じことは家電についても言えるはずで、日本からの基調講演では産業界からCE （ Consumer Electronics）における要求工学について紹介があったが、海外に比べると学会を巻き込んだ系統的な取組みについてはまだこれからというのが、我が国の現状だという意見もでていた[2]。   図1 立命館大学  図2 要求工学国際会議2004 基調講演 ◆ How Creative Design Happens,Nigel Cross（The Open University,UK） 創造的なデザインのプロセスを実証的に研究していくと、異なる分野のデザインにも共通する一般モデルがあることが分かってくる。クロス教授は、建築、F1、工業製品分野などにおける優れたデザイナーが仕事を進める上での認知的なプロセスに着目して、この一般モデルとは何かを研究してきた[3]。 要点を示すと図３のようだ。まず問題の解に対する狭い評価基準を使わないで、問題に対して広い意味でのシステムアプローチをとる。問題を独特の方法で問題の枠組みを定めていく。第一原理に基づいてデザインする。第一原理の例として、たとえばF1自動車の場合には、空気力学的なダウンフォースを挙げて説明した。つまり絶対的に従わなくてはならない原理を発見して、それを満足する解の概念を導き出すというものである。この解を評価基準に従って検証することで問題のゴールを達成することができるという。 クロス教授は、たとえば荷台付きのマウンテンバイクの設計実験では、プロトコル分析という手法を用いて、このような認知プロセスを科学的に解明している。ここで、プロトコル分析というのは、人間が作業を進めるときに、同時に、いま何をしようとしているかを発言してもらい、それを記録することにより、そのときの思考過程を推定する方法である。クロス教授の実験では発言を記録するだけでなく、4台のビデオも用意して、ホワイトボードにデザイナーが書いたイメージやそのときの動作を含めて記録し、詳細な分析を実施している。プロトコル分析は認知心理学ではよく用いられる方法であり、筆者らもソフトウェアの要求分析プロセスを解明する研究の中で用いたことがある。ソフトウェアもこれらの工業的なデザインと同じように、何かを作りたいという要求があり、それに対するソリューションをデザインするという点では共通性があるに違いない。ただし、ソフトウェアの場合には、物理的な制約がないので、必ずしも明確な第一原理は見つけられないかもしれないが、性能条件や、ソフトウェアを利用する人間の制約に基づいた何かしらの原理はあると思われる。いずれにしても、プロトコル分析は、もう一度、要求工学の科学的な研究の中で見直されてもいいかもしれないと懐かしく感じた。  図3 創造プロセス戦略の一般モデル(CROSS) ◆Toward Realizing the Ubiquitous Network Society, Ikuo Minakata（Matsushita Electric, Japan） 松下電器の南方氏がCE（Consumer Electronics, 家電分野）における松下電器の取組みについて報告した。家電製品がデジタル化されてきており、家電分野でもソフトウェアの要求工学が重要になってきている。松下電器の戦略も、80年代はHA（Home Automation）、90年代はHII（Home InformationInfrastructure）、2000年代はeHIIと発展してきた。今後は家電製品が家庭内だけでなく、携帯電話や携帯端末、自動車などのカーナビ端末などと連携するユビキタスネットワーク化が重要になっていく。したがって家庭、モバイル、自動車を連携するeLiveと、それらに対して社会的にサービスを提供するeService を組み合わせたeLive+eService という考え方が必要だ。 松下電器はこのようなサービスのOSとしてLinuxが重要だと考えており、家電向けLinuxに対する要求条件をCE Linux フォーラムの中で提案している。これまでの要求の例としてはリアルタイム性、高信頼性、メモリ足跡管理、電力管理、ブートアップやシャットダウンの高速化などがあった。これからの要求の例としてはサービス開発の容易性、一般消費者の立場に立った要求、市場からの要求などがあり、これらの開発者側からは見えない要求をいかに獲得していくかが課題となる。 ◆ Goal-Oriented Requirements Engineering: A Roundtrip from Research to Practice, Axel van Lamsweerde（University of Louvain, Belgium） ゴール指向要求工学（ Goal - Oriented Requirements Engineering,GORE）ではゴールを用いて要求を抽出、推敲、構造化、仕様化、分析、合意形成、文書化、修正する。ゴールは複数の視点からモデル化され、ゴール、オブジェクト、エージェント、シナリオ、操作、領域知識などの相互関係を現状のシステム（system-as-is）と同時にあるべきシステム（system-to-be）についても記述する。ゴールはソフトウェアとその環境におけるエージェントの協働により達成される意図を規定するものである。ここで、エージェントはソフトウェア、人、デバイス、レガシーシステムなどをモデル化した概念である。 ゴールはAND関係とOR関係で階層的に詳細化される。あるゴールをAND関係で複数のサブゴールに詳細化したとき、そのゴールを達成するためには、すべてのサブゴールが達成される必要があることを示す。またOR関係であるゴールを複数のサブゴールに詳細化したときは、どれかのサブゴールが達成される必要があることを示す。ゴールには、抽象的なレベル、戦略的な目標レベル、単一のエージェントに割り当てられる役割としての技術的な規定レベルなどがある。ソフトウェアに対応するエージェントに割り当てられるサブゴールがそのソフトウェアに対する要求に相当する。 このように、ゴールが階層的に詳細化されるので、トップダウンな手法であると誤解されることが多いが、そうではなく、シナリオ指向やエージェント指向との親和性が高いことをLamsweerde教授は指摘した。 またゴールには機能的なゴールと品質属性ゴールがある。機能的ゴールはUMLのユースケースに対応しており操作的に記述する。品質属性ゴールは非機能要求に対応しており、ソフトゴールともいう。 GOREの実践的な事例としてはKAOS（ Keep All Objective Satisfied）プロジェクトがあり、テレコム、航空機制御、ロケット制御、鉄鋼業界などでの適用実績がある[4]。実践・研究の双方にとってよい結果が出ているようである。またゴールモデリングツールFAUSTも実現されており、妥当性の検証もできるようになってきている[5]。 論文表彰 こ論文表彰では、RE04の中での最優秀論文とICRE’94の中で最も影響を与えた論文の２編が紹介された。 ◆Best RE’04 Paper Award:“COTS Tenders and Integration Requirements”, S.Lauesen, IT University, Glentevej 67 Lauesen教授の論文では、商用コンポーネント（COTS）製品を用いて他のシステムと統合するときに有用となる要求の実践的な提示方法として、「オープンターゲット要求」の概念を経験に基づいて提案している。従来のような要求の提示の仕方では、ソリューションとしてのCOTSの具体的なインタフェースが明確にできないため、他のシステムと統合しようとしたときに問題が発生してしまう。このためCOTSが想定するインタフェースをオープンターゲット要求で半構造的に可能な限り指定する。オープンターゲット要求の例は次のようになる。 例：システムはデータをLabsysXと共有する必要がある。顧客は最新の結果がEPR システムで常に表示されることを期待している。提供者はソリューションを説明するように質問される。 このように、ソリューションを説明する観点をオープンターゲット要求として指定するのである。この論文では統合しやすいCOTSを購入するために、次のようにしてCOTSの選定プロセスを改善することができるとしている。 （１）オープンターゲット要求を用いてCOTS提供者が製品を半構造的に説明する。 （２）各要求を技術的な機能の観点ではなくユーザーからの要請として表現する。これにより提供者のソリューションをよく知ることができる。 （３）統合のレベルを指定することにより、提供者が提供するCOTSの統合レベルを判断する。 （４）第三者が製品を拡張できることを確認するための要求を指定する。この要求では必要なインタフェース、文書の有効性、インタフェースと文書の使用権を含んでいる必要がある。 （５）契約後に短い試用期間を利用して提供者が製品の高リスク部分を確認できるようにする。 ◆Most Infruential Paper Award:“An Analysys of the Requirement Traceability Problem”, Oriena C.Z.Gotel and Anthony C.K. Finkelstein Finkelsteinらの論文は、100人を超えるソフトウェア開発者へのヒヤリング、そして100件を超える文献とツールの調査、さらには、５社にわたる37人の技術者への詳細なアンケート調査と事後分析という実証研究に基づき、要求追跡性についての本質的な問題点を整理している。 この論文によると、要求追跡性には、プリRS追跡性とポストRS追跡性の2 種類を区別する必要があり、それまでの研究やツールではポストRS追跡性しか考慮していないが、実はプリRS追跡性が重要であるというものであった。ここで、RSというのは要求仕様書requirements specificationのことである。したがって、プリRS追跡性というのは、顧客からあいまいな要求を抽出し、要求仕様書を作成するまでに発生する要求と要求仕様書との関係の追跡性のことである。ポストRS追跡性というのは要求仕様書に記述された要求間の関係の追跡性のことである。 また彼らは、この事実を踏まえて、今後想定される重要な研究課題として、次の３点を指摘した。 ・プリRS 追跡性における要求の情報源の発見とそのアクセス支援 ・非形式的なコミュニケーションの活性化支援 ・要求の作成・仕様化・保守と利用の基盤となる社会的な構造の継続的なモデリング この論文で提案されたこれらの課題は、要求を獲得し仕様化する上での顧客や運用者などの開発されるソフトウェアに対する利害関係者との深いコミュニケーションが重要であることを指摘したものであり、要求工学における社会科学的な研究の必要性を提唱するものであった。これらの課題については、要求に関する利害関係者や情報源となる文書などと要求仕様との参照モデルを提案する貢献構造（Contribution Structure）の研究など現在でも多数の研究が進められている。 その他の話題 主なセッションには、要求追跡、アスペクト指向、非機能要求、産業界からの報告、社会工学的研究などがあった。筆者はIndustry Reports１:Selecting & Managing Requirements Processes & Toolsのセッションの座長を担当した。このセッションでは、要求管理ツールを選択するための要求についてのダイムラークライスラーからの発表、CRCカードを用いた簡便な要求管理ツールの使用経験報告、HPでの部門ごとの要求工学プロセスの選択手法の発表などがあった。 また、ベンダープレゼンテーションでは、NTT データからMOYA（Model-Oriented Methodology for Your Awareness）の紹介があった。MOYAでは様々な手法を統合的に用いて、関与者、課題、目的、手段、業務をモデリングし、要求定義の精度を向上させることができる。 MOYAで統合している手法には、ソフトシステムズ方法論（SSM）、ゴール指向分析、エッセンシャルユースケース、UMLによる多視点モデリングがある（図４）。  図4 MOYA全体像 以上述べたように、本稿では京都で開催されたRE04の主要な話題について紹介した。 参考文献 [ １] 第12回要求工学国際会議, http://www.re04.org [２]「要求分析の体系化は欧米に遅れている」、要求工学国際会議の議長 http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040913/149852/index.shtml [３] Nigel Cross, Creative Cognition in Design: Processes of Exceptional Designers, T. Hewett and T.Kavanagh (eds.) Creativity and Cognition, ACM Press, New York,USA, 2002. [４] Goal-Driven Requirements Engineering:the KAOS Approach http://www.info.ucl.ac.be/research/projects/AVL/ReqEng.html [５] The FAUST toolbox for Formal Requirements Specification Analysis http://www.cetic.be/internal.php3?id_article=73
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
