ICTソリューション総合誌　月刊ビジネスコミュニケーション

ホーム >  要求工学 >  2007年8月号 >  第34回：要求工学の研究動向 

前回紹介したゴール思考の考え方を８月27日から開催されるソフトウェア工学シンポジウム（http://ses2007.cs.shinshu-u.ac.jp/participate.html）のチュートリアル「ゴール思考で防ぐIT開発の失敗」と題して解説することになった。興味のある方はぜひ参加していただきたい。

さて、今回はFOSE（Future Of Software Engineering）2007のサーベイ論文[1]をみると、対象システムの拡大に伴って、要求工学でも大規模性、セキュリティ、耐久性、環境依存性、自己管理性を持つシステムに対する研究が必要になってきていることがわかる。またソフトウェア開発形態の変化としてグローバル化に対応する要求工学も求められている。さらに従来からの課題として、要求工学手法の適用法や再利用と有効性の実証に関する研究も必要である。

今回は、このような注目されている要求工学の新しい研究領域を紹介しよう。

大規模性

ソフトウェアシステムのスケールはコード数だけでなく複雑性、多様性、センサー数、分散ノード数などの点で増加している。また、ソフトウェアが組み込まれる環境変化に従ってソフトウェアへの要求の数も増加する。

このような大規模化するスケールファクタを持つシステムをULS（ultra-large-scale）システムと呼ぶ。ULSの例には、軍事指令制御システムやITS、統合健康管理システム、災害応答システムなどがある。

ULSシステムが持つ大規模性、複雑性、可変性、あいまい性を伴う要求をうまくモデル化して統合する新たな要求工学手法が必要になる。

セキュリティ

ソフトウェアが生活環境に浸透していくに従って、管理される個人情報が増加するのでセキュリティ攻撃から個人情報を保護することが重要になる。このため、脆弱性対策、システムと情報の保護、攻撃への防御と回復などについて、個別的ではなくシステム全体としてセキュリティ要求を戦略的に定義する必要がある。また段階に応じてどこまでセキュリティ要求を詳細化するか、性能や操作性などの非機能要求とセキュリティとのトレードオフについても議論する必要がある。

耐久性（トレランス）

大規模性、意思決定の分散性、可変性を持つソフトウェアに対しては、セキュリティや正当性についての要求条件を緩和する必要がある。Shaw[2]はこのような考え方を「十分な正統性」として提案している。

---

システムの利用者が意図する目的を維持し、ユーザの現在のニーズと期待を十分に満足させるようにシステムがデペンダブル（持続可能）であるとき、このシステムは十分な正当性を持つという。

このような十分な正当性では、システムが正当であることの十分性（つまり、どの程度、正当なのか）についての尺度（度合い）をどのように定義するかが重要になるだろう。

また、不確実で動的に変化する環境の中で動作するようなシステムは、必然的に不安定な環境を扱うことになるので、想定外の不都合な環境条件に遭遇すると所望の動作ができなくなる可能性が高い。この問題に対処するためには、システムが受容可能な振る舞いに対する環境の健全性についての要求を抽出しておく必要がある。

正当性の精度を緩和する一つの方法は、受容可能な振る舞いの範囲を拡張してシステムの耐久性に関する要求を決めることだ。また否定的な側面としての不健全性（どのような不都合な事態が考えられるか？）に着目して、その診断と回復のための要求を抽出することもできるだろう。

環境依存性

システムが大規模化する要因としては、ソフトウェア、ハードウェア、人が互いに関連するようなSOS（System Of Systems）が増えていることがあげられる。たとえば自動車では既に数千万行のソフトウェアが搭載されているし、次世代車載ソフトウェアでは1億行を越えると予測されている。

物理環境における実体の監視と制御に計算と通信が緊密に連携するシステムをCPS（Cyber-Physical Systems）と呼ぶ。ITSやセンサーネットワークなどのユビキタスサービスはCPSになる。動作する物理環境に依存してソフトウェアだけでなくハードウェア装置、オペレータや利用者などともCPSはインタフェースを持つことになる。このためCPSのシステム境界を定義する問題が、人間を含む多数の外部システムに対して責任の所在がどちらにあるのかを定義するという複雑な問題を含むことになる。つまり不測の事態に対してどちらに過失責任があるのかということも含めて要求定義することが求められるようになったということである。

また連続的に変化する物理環境をデジタル計算機で処理することになるのだから、CPSでは離散的に近似するしかない。したがって、CPSは環境を完全には把握できず、近似的に扱うしかないという意味では、本質的な不完全性をCPSが持つことを忘れてはならない。この点でもCPSでは、環境の近似精度を扱う必要がある。

自己管理システム

環境や要求に応じて変化するシステムを自己管理システム（Self-managing system）という。利用者の位置と地域のサービスプロバイダに応じて提供サービスが変化する携帯デバイスは自己管理システムの例である。携帯を使っていてよく遭遇する例は電波が届かなくなる「圏外」という事象だ。圏外になってメールが送信できなくなると、未送信メールボックスに送信しようとしたメールが自動的に保存されるようになっている。これは圏外でメールが送信できなくなったことを携帯電話が認識して適切な次善の策としてメールを保存しているという訳だ。

またシステム障害から動的に回復できる自己回復システム（Self-healing system）や自己最適化システムも自己管理システムである。

要求工学の観点からの課題を列挙すると、次のようになるだろう。

• いつシステムを適応させるかという判断基準（閾値）を識別して仕様化すること
• 変化する可能性のある要求の集合を仕様化すること
• 実行時のニーズに対する要求の代替案を照合すること
• 適応型システムに対する正当性の基準を識別すること
• 適応型システムのモデルと可能な動作の集合を検証すること
• 現在の要求に対してシステムと環境を監視すること

適応型システムでは、開発時には想定していない環境条件や要求変化が発生する可能性もある。このような場合には、実行時に新しい要求や新たな動作を遂行できるように自己管理型システムを拡張した自己進化型システムが必要になる。たとえば、次のような取り組みが必要である。

• 動的に要求がどのように進化するかを定義すること
• 不確実性や予期しない環境条件に遭遇したことを判断するための基準
• 状況に即した適応動作を選択するための判断基準

しかし、このような方法の限界は、「予期できないことを定義できる」ことを仮定していることにある。将来的にはより挑戦的ではあるが、生命現象などが持つ進化の機構をまねた自己進化型システムに対する要求定義のしくみが必要になるかもしれない。

グローバル化

グローバルソフト開発（GSD,　Global Software Development）は24時間開発、国際的な開発資源のプール、コスト低減などを目的として国際的な分散開発チームを構築しようという取り組みである。

GSDでは、国際間で協働して要求を仕様化することと、定義された要求仕様と海外に発注される下流工程とのコミュニケーションギャップを解消することが重要になる。たとえば、どのようなコミュニケーション媒体の組合せが効果的であるかということやゴール、文化、プロセス、責任を交渉するためのベストプラクティスなどが研究されている。

GSDでは、３つのCとDが重要だと言う報告がある[3]。３つのCはコミュニケーション、コーディネーション、コントロールだ。これに対して３つのDとは時間的、地理的、社会文化的距離のことだ。

CとDについて、GSDのプラス面とマイナス面を評価すると、次のようになるそうだ。

コミュニケーションに時間的距離が与える影響

＋非同期コミュニケーションにより記録が改善

－同期コミュニケーションの機会が減少

コミュニケーションに地理的距離が与える影響

＋市場に近い

－労働力へのアクセスが遠い

－対面会議が減少

コミュニケーションに社会文化的距離が与える影響

＋イノベーションとベストプラクティスの共有が増える

－相互理解が困難

コーディネーションに時間的距離が与える影響

＋調整ニーズを最小化

－調整コストが増加

コーディネーションに地理的距離が与える影響

＋柔軟な調整を計画できる

－非公式的な接触が減少することでリスクに対する状況認識が低下する

コーディネーションに社会文化的距離が与える影響

＋豊富なスキルセットを獲得できる

－作業形態の不適合が効果的な調整の障害になる

－相互理解の不足から協働作業が減少する

コントロールに時間的距離が与える影響

＋24時間7日間いつでも作業できる

－生産物の作成が遅れる

コントロールに地理的距離が与える影響

＋コミュニケーションチャネルが監査から逃れることができる

－ビジョンや戦略を伝えにくい

－低コストのライバルを育成してしまう

コントロールに社会文化的距離が与える影響

＋文化に固有の積極性

－権限についての認識の相違に基づくモラルの低下

－地域の法制度への適合性

方法論、パターン、ツール

モデル化の慣用規約やパターンのような部分解を提供することで、要求分析作業の効率を向上できる。

また、現在の要求工学手法は個別的な技術の段階にとどまっている。将来はこれらを統合して一貫性のある要求開発プロセスを実現する必要がある。このため、モデル要素を理論的に統合する方法やプロジェクト管理上の留意点などが研究されている。たとえば、組込みソフトウェア開発のプロジェクト管理では次のような4つの技法をすべて適用することで納期遅延を劇的に抑止できたというAlcatelの報告がある[4]。このような技法の統合では要求定義プロセスだけではなく生産物をどのように構成するかについても考慮する必要がある。

●製品管理者、マーケティング管理者、プロジェクト管理者からなる多機能コアチームの組織化

●製品ライフサイクルを上流工程でゲートレビュすること

ゲートレビュの目的はコミュニケーションとリスク管理である。たとえば重要な意志決定点として、ビジネス分析、プロジェクト定義、プロジェクト実行、保守などの工程で、プロジェクトの継続もしくは停止を判断するためにゲートレビュを実施する。ビジネス分析が上流工程になる。つまりプロジェクトを定義する前に製品ライフサイクルを全体をゲートレビュすることが重要になる。ゲートレビュウでは、プロジェクトの状況を予め定めた判断基準に基づいて評価する。ポートフォリオにより、製品全体を対象にして、各製品の対象市場、投資額を定める。

多様な観点からの要求の評価

ビジネス性や変更管理ならびに優先順位について要求の妥当性を確認することが重要である。また影響分析では、製品管理、マーケティング、プロジェクト管理の観点から要求を評価するだけではなく、その優先順位やポートフォリオについても評価する必要がある。

多機能コアチームは以下のような観点から要求を評価して結果を文書化する。

• 要求は何か？
• 市場や他の要求とどのように関連しているか？
• 要求が何に影響するか？
• どの市場がどんな理由で製品や要求を求めるのか？

このような要求評価と文書化によって、市場に即した製品開発が可能になると思われる。たとえば、要求仕様書のレビュはしていても、このような観点を明確にしたレビュを実施していない場合が多いのではないだろうか？レビュの観点を明確にすることで、それに応じた適切な品質評価ができるようになると思われる。

製品ポートフォリオの持続的な保証

ここで持続的な保証というのは、マイルストーン、内容、品質目標についてコミットメントを保守することである。同じプロダクトラインに属するある製品のプロジェクト計画が変更されたら関連する製品の計画や要求についても同期して修正する必要がある。

ポートフォリオ情報の管理では関連する情報がプロジェクトをまたぐので変更管理作業を効率化するための自動化が必要になる。

要求の再利用

既存の要求資産を再利用するためには、要求のプロダクトライン化が有効である。関連するソフトウェア製品をまとめた製品ファミリを構成しておき、最初からこれらの開発をまとめて計画するのである。共通要求を再利用テンプレート化することで、各製品に対して個々の要求をテンプレートから作成することができるようになる。

要求のプロダクトライン化では、ドメイン分析、プロダクトライン化の契機の識別、製品ファミリの範囲、共通性や差異性の識別、共通性の文書化などが課題である。

再利用可能要求では、コンテクスト、問題、結果、性質などをパターン化することとそれを各適用ドメインに応じて具体化することが必要になるが、一般的な手法はまだないのが現状である。

要求工学の有効性

要求工学研究の影響力は産業界のニーズにどれだけその結果が合っているかに依存する。これまでのところ要求工学研究が産業界の問題をどれだけ良く解決したかについてはほとんど評価されていない。要求工学の実証的な研究のほとんどは、概念検証かパイロット研究の段階である。つまり特定の問題について概念や技術の有効性を確かめているだけである。

これに対して開発者は新技術が教育、文書化、プロセス変更などのオーバヘッドを正当化するために、これらのコストに対しても有効であるという確実な証拠を求めている。したがって実証研究でも、このような費用と便益に関する定量的な分析が必要である。

まとめ

今回はFOSE2007で報告された要求工学の研究動向[1]に基づいて、要求工学の最近の関心領域を説明した。今後も複雑化するシステムと多様化するシステム開発形態に即した実務に役立つ要求工学の研究が進むことを期待したい。

---

■参考文献

• [1]Betty Cheng and Joanne Atlee, Research Directions in Requirements Engineer- ing,FOSE 2007.
• [2]M.Shaw.“Self-Healing”;Softening precision to avoid brittleness.In Work.on Self-HealingSys.(WOSS).November 2002.
• [3] P. Agerfalk and B. Fizgerald, Flexible and distributed software processes: old petunias in new bowls?, CACM, pp.27-34, vol.49, 2006.
• [4] Christof Ebert, Understanding the Product Life Cycle: Four Key Requirements Engineering Techniques, IEEE Software, pp.19-25, 2006.