|
|
概 要 要求工学はソフトウェア開発における要求仕様化プロセスを工学的に定式化する技術として注目を集めている。今年は第12回の要求工学国際会議（International Conference on Requirements Engineering,ICRE）が日本の京都で９月６日から11日まで立命館大学の衣笠キャンパスで開催される[１]。本稿では、要求工学の概要と要求工学の本質的な要素を明らかにするとともに、要求工学の価値について述べる。最後に要求工学の課題を紹介する。 要求工学の必要性 要求工学（ Requirements Engineering）は新しい技術ではなく1970年代から議論されている。ソフトウェア危機が1960年代に認識されたときに、ソフトウェア開発プロジェクトが失敗する主要な原因が要求の欠陥にあると報告されている[２]。 開発したソフトウェアが納入され変更することなく使われたとき、開発プロジェクトは成功したといえるだろう。ソフトウェア開発プロジェクトが失敗するのはこの逆で、次のような場合が考えられる。 a）納入できなかった b）納入されたが使われなかった c）納入され使われたが廃棄された d）納入されたが変更した上で使われた これらの原因は以下のようなソフトウェアの要求仕様に関する問題に帰着できる。 a）要求仕様が不完全やあいまいで望まれるソフトウェアを実現できなかった b）要求仕様を満足するソフトウェアを開発したが、要求仕様が顧客の目標にあっていなかった c）要求仕様を満足するソフトウェアを開発したが、変化した顧客の目標に対してソフトウェアを修正できなかった d）要求仕様を満足するソフトウェアを開発し、変化した顧客の目標に対してソフトウェアを修正する必要があった これらの問題を解決するためには、ソフトウェア開発の上流で可能な限り完全に顧客要求を確定しておくことが重要になる。c）d）については、予めソフトウェアが使用されたときの状況を想定することにより、要求変化を考慮した要求仕様を作成する必要があることを示している。実際にはソフトウェアを使って見ないと分からない要求もあるので、継続的なソフトウェア進化の中で要求仕様の成長を考える必要があるだろう。 このようにソフトウェアの要求仕様は、だれでも自然に記述できるものではなく、系統的な手法により、抽出した要求仕様を継続的に検証して更新していく必要がある。つまりアドホックな要求仕様作成ではなく、定式化された要求仕様の作成方式が必要だということで要求工学の重要性が認識されたのである[３]。要求工学の目的は、要求を分析し文書化することに関する科学および原理を解明することにより要求分析を効率化しソフトウェア開発を成功させることであるといえよう。 要求工学とは ここで要求工学の定義を文献から見てみよう。 定義１Ramamoorthy[４] 要求工学は、ユーザ要求を仕様化するプロセスである。作成された仕様がシステム開発の設計、製造、試験工程をガイドする。 定義２ SWEBOK[５] 要求工学は要求の系統的な処理を表す。ソフトウェア要求は要求工学プロセスから生じる生産物である。 定義３ Kotonya[６] 要求工学は、コンピュータシステムに関する要求の集合を、発見、文書化、保守することに関するすべての活動を対象とする。要求工学では系統的で反復可能な技術を用いてシステム要求が完全、無矛盾、実際的であることを確認する。 定義４ Loucopoulos[７] 問題分析時に相互作用的で協調的なプロセスにより要求を生成すること、観察結果を種々の表現形式により文書化すること、取得された理解の精度を検討すること、これらをシステム的に行うプロセスのことをいう。 定義５ Zave[８] 要求工学はソフトウェアシステムに関する実世界のゴール、機能、制約を扱うソフトウェア工学の分野である。要求工学では、これらとソフトウェアの振る舞いに関する正確な要求仕様との関係や、時間ならびに関連するソフトウェアに関してこれらの要因がどのように進化していくかについても扱う。 このように要求工学の定義には、ソフトウェア要求仕様を作成するプロセス（定義１〜定義４）とソフトウェア工学研究の分野（定義５）との2つがある。以下ではまず要求工学プロセスを構成する要素について紹介する。次いで要求工学の主要な研究課題を概観しよう。 要求工学プロセスの構成要素 SWEBOKでは、要求工学プロセスを、要求の抽出、要求分析と折衝、要求の仕様化、要求の妥当性確認と要求管理から構成している。これらの活動では、まず非公式に提示された要求が合意された要求になり、その要求が仕様書として文書化され、さらに妥当性が確認されるという過程がスパイラルモデルで反復的に繰り返される。 ◆要求の抽出 ステークホルダ（システムの利害関係者：経営者、発注者、ユーザ、運用者など）、文書、業務知識（ドメイン知識）市場調査などからシステム要求を見つける。このプロセスは要求の発見や獲得などとも呼ばれる。要求抽出では、インタビュー、シナリオ分析、プロトタイピング、打合せ、ユーザ行動の観察などの手法を用いる。 ◆要求分析と折衝 要求分析では、異なるステークホルダから抽出した要求間の競合を解決し、システム化の範囲を明確化する。このため要求分析では、適切なモデルを用いて要求の構成要素間の関係を理解する。このような要求のモデルには、データフロー、制御フロー、イベント、ユーザインタフェース、オブジェクトなどがある。要求を具体化する過程で、ソフトウェアのアーキテクチャを考慮して、どのコンポーネントが要求に対して責任を持つかということを検討する場合がある。つまりシステムをどのようなアーキテクチャに基づいてコンポーネントに分割し、要求をどのコンポーネントに割り当てるかを考える。 要求の折衝では、ステークホルダ間、機能と制約間などで発生する要求間の競合を解決する。このためには競合解決のためのトレードオフについて合意を形成しておく必要がある。 ◆要求の仕様化 合意された要求についてすべてのステークホルダが理解できるように文書化する。したがって対象業務の用語を用いて記述する必要がある。また開発者が設計や製造で参照できるように定式化されたモデルで要求を適切な詳細さで文書化することも必要である。 ◆要求の妥当性の確認 要求の一貫性と完全性をソフトウェアの設計や製造を始める前に検証しておく必要がある。要求仕様書のレビュ、プロトタイピング、モデルを用いた形式的な検証などの手法がある。 ◆要求管理 要求管理ではソフトウェア開発の全工程で次のようにして要求を管理する。まず合意された要求を識別し、要求の内容を管理する。また指定された要求に対する変更を管理する。さらに要求間の関係や要求とソフトウェア開発に関する他の文書との関係を管理する。 ◆従来の要件定義手法との違い ここで、従来の要件定義[９]や要求分析[10]と呼ばれていたソフトウェア開発の上流工程と、要求工学との主な違いをまとめておくと次の２点であろう。 ・プロセスモデルの違い 要求工学ではスパイラルモデルにより反復的に要求の仕様が成長していくと考える。このためソフトウェア開発の全工程にわたって要求を管理することの重要性が認識された。これに対して、従来の要件定義ではウォータフォールモデルにより、要求仕様を上流工程で確定してから、下流工程に進む開発工程を想定していた。 ・アーキテクチャの考慮 1980年代までは、要求仕様ではシステムの実現方法（How）ではなくシステムの目的（What）を記述するべきであると考えられていた。たとえば文献[10]では「要求分析とは、利用者のニーズを明らかにして、システムやソフトウェアに対する外部特性を記述するプロセスである」と述べている。しかし、1990年代に入って、C/Sやインターネット、コンポーネント、Webサービスなどの新しいソフトウェア技術の登場により、アーキテクチャを前提にして要求仕様を記述するようになってきている。SWEBOKでも、すでに述べたように要求工学プロセスでアーキテクチャ設計を考慮している。 要求工学の価値 要求工学がソフトウェア開発にもたらす作用には、次のような受容性と完全性の向上という２つの方向がある。 （１）発注者による受容性の促進： 発注者の目的に適した要求仕様を記述することで、納入後も継続的に使用できるソフトウェアを提供できソフトウェアの受容性が向上する。 （２）開発者による完全性の実現： このような要求仕様を満足するソフトウェアを開発することでソフトウェアの完全性を向上できる。 また要求工学の価値をソフトウェアの開発工程ごとに考えてみると次のようになる。ソフトウェア開発の工程には分析、設計、製造、試験、保守がある。分析工程では系統的な要求工学手法を用いることにより完全性の高い要求仕様を作成できる。設計工程では、設計したソフトウェアの構成要素が要求仕様を満足することを検証することにより設計の妥当性を保証できる。製造工程では、コードの必要性を対応する設計の根拠となる要求を追跡することで確認できるだけでなく、コード変更の波及効果も分析できる。試験工程では試験仕様を要求仕様に基づいて作成することにより、信頼性の高い試験を実施できる。またソフトウェアの誤りを修正するために必要なコストの相対比は、要求分析：設計：製造：試験：保守で１：５：10：50：200であるといわれている[11]。 この理由は下流工程に行くほど、誤りの検出が困難になるだけでなく、手戻りがより多く発生するためである。したがってできるだけ要求工学プロセスの段階で誤りを発見することが望ましい。 要求工学の研究課題 要求工学における主要な研究課題の例を要求工学プロセスごとに示すと次のようになるだろう。 ◆要求抽出 ・ステークホルダをどのようにして発見するのか？ ・ステークホルダからどうやって要求を抽出すればいいのか？ ・要求エンジニアとステークホルダや開発者がどのようにして協調作業をするのか？ ・要求エンジニアにはどのようなスキルが必要になるのか？ ・要求間の優先順位をどのようにして抽出するか？ ・要求の必要性の根拠や議論の記録をどのようにして管理すればいいのか？ ・ソフトウェアが要求を満足するための条件をどのようにして抽出するか？ ・いつまで要求抽出を続けるのか？ ・業務文書からどのようにして要求を抽出できるか？ ・システム化の範囲をどのようにして決めればいいのか？ ・種々の要求抽出手法をどのようにして統合すればいいのか？ ◆要求分析・折衝 ・多様なビュウ（視点）ごとに異なる表現を持つモデルをどうやって統合すればいいか？ ・業務知識をどのようにしてモデル化すればいいのか？ ・業務知識をどのようにして標準化すればいいのか？ ・業務行動をどのようにして分析すればいいのか？ ・要求に対する必要性をどのように定量的に定義すればいいか？ ・あいまいな要求をどのようにして具体的な性質や機能に変換すればいいのか？ ・どのようにしてシステムの構成要素に要求を割り当てればいいのか？ ・要求に対する代替案をどのようにして評価するのか？ ◆要求仕様化 ・要求をどのようにして文書化するのか？ ・要求仕様をどのような言語で記述すればいいのか？ ・要求から設計や実装に適した具体的な要求仕様をどのようにして作成するのか？ ・要求仕様をどのようにして標準化すればいいのか？ ・システムに対する制約や品質などをどのようにして仕様化すればいいのか？ ・ステークホルダごとに適切に仕様化するにはどのようにすればいいのか？ ◆要求の妥当性の確認 ・要求に対する完全性や一貫性をどのようにして定義し評価するのか？ ・要求の妥当性の判断基準をどう定義するのか？ ・要求に対するコスト、実現性、スケジュールなどをどのようにして評価するのか？ ・要求の評価尺度をどのように定義するのか？
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
