ホーム > 要求工学 > 第6回 要求分析

NTTデータ 
技術開発本部 副本部長 
山本修一郎

概 要

 
要求分析では、抽出された要求を分類して要求間の競合を解決する。要求の分類では要求を理解するために概念モデルを作成する。またアーキテクチャを考慮してシステムの構成要素に要求を対応付ける。競合解決では関係者との合意に基づいて要求間の優先順位を明らかにする。本稿では、要求分析手法を概観する。

要求分析の位置づけ

 まず要求工学プロセスの中での要求分析の位置づけを復習しておくと、次のようになる[1][2]。要求工学プロセスには、要求抽出、要求分析、要求の仕様化、要求確認がある。要求抽出と要求分析までが問題領域に関するプロセスである。これに対して要求の仕様化と要求確認がソリューション領域のプロセスである。要求分析では、要求抽出で獲得した要求間の関係構造や一貫性を明らかにする。要求分析では要求間の優先順位を明確化して顧客との合意を形成する。この過程で概要レベルの要求が具体化される。

要求の分類

 要求を分類する観点については前回紹介したように経営目標、ビジネスプロセス、機能、制約(非機能)などがある。またデータ要求、機能要求、状態要求という分類もできる。
 またシステムのアーキテクチャを考慮して、どの構成要素(サブシステム)で要求が必要とされるかという有効範囲で要求を分類することもできる。この場合システムの構成要素ごとに要求を対応付ける必要がある。
 もし要求が適切に分類されていれば、選択した分類を視点として多面的に要求を分析できる。たとえば、次のようにして要求を分析できる。まず、同じ分類内に属する要求間の類似性や一貫性などを確認する。次いで、互いに関連する要求が異なる種別(たとえば優先順位)に分類されていないか確認する。他の分類についても同様の分析を実施する。たとえばデータ、機能、状態という3つの側面から要求を多面的に分析できる。この他にも関係者ごとに必要な要求を分類して分析することもできる。
 要求の優先順位の値により要求がどの程度必要とされているかということでも分類できる。たとえば、次のような4段階で要求を分類できる。

・必須(mandatory)
・強く望ましい(highly desirable)
・望ましい(desirable)
・任意(optional)


 要求の優先順位は、より優先順位の高い要求を採用することで、要求間の競合の解消や、開発コストなどの資源制約を満足させるために必要な要求を選択する場合に用いられる。

要求分析の確認項目

 要求分析では次の5項目を確認する必要がある[2]。要求の妥当性の確認でも同様の項目を検討する。要求分析段階では要求仕様書として記述する前に抽出された要求を対象として確認する。これに対して要求の妥当性確認段階では要求仕様書について妥当性を確認する点が異なる。要求仕様書に書いてから誤りや冗長性を発見するよりも分析段階で確認しておいた方が効率的である。

◆要求の必要性

 システムが対象とする経営目標の実現に貢献しない要求や不必要な要求が混入していないことを確認する。要求の必要性に対して優先順位を割り当てることができる。

◆要求間の類似性

 抽出された要求同士が互いに重複していないことを確認する。複数の要求が重複する場合には、冗長な要求を削減することでシステム開発を最適化できる。

◆要求間の一貫性

 抽出された要求同士が互いに矛盾しないことを確認する。矛盾する要求間に優先順位を割り当てることで、要求の競合を解決できる場合がある。

◆要求の完全性

 必要な要求がすべて抽出されていることを確認する。要求の完全性を確認するためにはシステムの開発目標が具体的に抽出されていることが必要になる。

◆要求の実現可能性

 抽出された要求を実現するために、技術的に開発可能であることと、必要な経費や開発期間、開発要員が用意されていることが必要になる。
 要求の優先順位に応じて開発経費や開発期間を満足するように要求を選択できる。

要求分析プロセス

 前述した要求の分類と確認項目に従えば、次のような要求分類プロセスを構成できる。

◆要求の分類 

 要求の種類を明らかにし、種類ごとに要求を多面的に整理する。

◆要求の確認 

 要求分類に基づいて要求間の関係を分析することにより、類似性、一貫性、完全性を確認する。また要求の必要性や実現の可能性についても明確化する。

◆関係者の合意 

 要求の問題点ごとに適切な関係者との間で問題点の解消について合意する。要求を構成する要素間の関係を分析するために、次に述べるような概念モデリング手法が提案されている。

概念モデリング

 要求分析で用いられる概念モデルには次のようなものがある。

(1)データフローモデル

 システムの外部環境やプロセス間で入出力されるデータの流れに基づいて構成要素間の関係をモデル化する方法である。データフローの見方を変えると、入力データを出力データに変換する一連のプロセスを表現していると考えることもできる。データをモノに置き換えると、入力となる部品を加工して最終製品を製造するプロセスをデータフローモデルで表現できることがわかるだろう。この場合、プロセスはモノに関する「コト」を表すのである。

(2)制御フローモデル

 プロセス間の制御の流れに基づいて構成要素間の関係をモデル化する方法である。

(3)状態モデル

 イベントによる状態遷移に基づいて構成要素間の関係をモデル化する方法である。通信分野やリアルタイム分野では代表的な表現法だ。UMLではアクティビティ図で記述する。

(4)イベントシーケンスモデル

 サブシステム間で交換されるイベントとその応答の時間的な順序系列に基づいて構成要素間の関係をモデル化する方法である。状態モデルと同じように通信分野やリアルタイム分野で用いられることが多い。UMLではシーケンス図で記述する。

(5)オブジェクト指向モデル

 オブジェクトを構成する属性とその操作に基づいて構成要素間の関係をモデル化する方法である。オブジェクト間の関係には、メッセージの交信に基づくオブジェクトの操作関係と、属性の継承に基づく一般化関係(generalization, is-a関係)、あるオブジェクトが他のオブジェクトを要素とする包含関係(aggregation,part-of関係)がある。

(6)ゴール指向モデル

 前回説明したように、ゴールとなる要求を部分要求(サブゴール)に段階的に展開していくことにより、要求間の関係をモデル化する方法である。機能要求と非機能要求との関係を2次元の表で分析することができる。この場合、非機能要求がゴールで機能要求がゴールに必要なサブゴールになる。もし非機能要求に対応する機能要求がなければ機能が不足している。機能要求に対する非機能要求が存在しなければ、この機能要求は必要がない可能性がある。
 またゴール指向モデルで代替案を分析することもできる。たとえば、代替機能要求として案1 と案2 があるとする。これらを比較するためには比較基準として、性能、柔軟性、変更容易性などの非機能要求が必要となると仮定する。代替機能に対する非機能要求の評価(たとえば◎、○、△、×などでもよい)を要素とする表を作ることにより、機能要求案1と案2に対する非機能要求の関係を分析できる。ここでは、ゴールが部分要求としての性能、柔軟性、変更容易性のすべての非機能要求を可能な限り満足することであり、これらの非機能要求を達成するのが機能要求案1か案2のどちらかであるということになる。このように考えると、非機能要求などと難しいことを持ち出さなくても、比較表を用いた代替案の検討は、昔からちゃんとやっていることであって、ゴール指向分析などで定式化される前からみんな知っている。つくづく実務は理論よりも先行しているものだと感じる。とはいえ、定式化しておくことで要求が持つ曖昧性を排除し分析作業を標準化できるので作業効率を向上できると思われる。

(7)概念データモデル

 システムが処理対象とするデータの構造を論理的に分析する方法である。データを格納するエンティティとその関係を分析する関係モデルでは、属性の集合でエンティティを定義する。関係モデルでは1:1、1:多、多:多などの次数によりエンティティ間の関係を詳細に分析できる。

(8)形式的モデル

 要求機能や振る舞いを表現するための構文だけではなく、意味も数学的に定式化することにより、構成要素間の関係を厳密にモデル化する方法である。高い信頼性が必要とされるシステムのモデル化に適用されている。形式的モデルでは、構文と意味を厳密に定義する必要がある。たとえばこれまで曖昧とされていたUMLの図の表現( 構文) をUML2では正確に定義しただけでなく、図を構成する要素の振る舞いをアクションセマンティクスで厳密に定義する。MDAではこのような形式的モデルに基づいてコードを自動生成することを狙いとしている。

(9)ビジネスモデル

 ビジネスに関するプレーヤ間の取引関係をモデル化する方法である。クラス図で記述する場合はプレーヤをオブジェクトとし、オブジェクト間のメッセージの交信関係で取引内容を表現できる。この場合、メッセージとしては注文依頼や送り状のような情報だけではなく商品や料金なども記述する。このようにメッセージの交換を表現できればビジネスモデルを記述できるので、シーケンス図やアクティビティ図でも記述することができる。

(10)ビジネスプロセスモデル

 ビジネスプロセスはビジネスゴールを実現するための業務手順をモデル化する方法である。業務手順の要素にはソフトウェアが実現する機能と人間の作業があり、データフローモデルやイベントシーケンスモデルで表現できる。データフローモデルの場合、プロセスで機能やヒトの作業を表現する。イベントシーケンスモデルではサブシステムが機能やヒトのビジネスプロセスに対応する。
 ここで、情報システムに対する要求について考えてみると、まず情報システムで解決すべき経営課題としてのゴール要求があり、それを達成するためのビジネスプロセス要求が必要だ。このビジネスプロセス要求の一部に情報システムの機能要求があるはずだ。したがって、非機能要求としてのゴール要求と機能要求は、ビジネスプロセスによって関係付けられる必要があるということだ。立派なシステムができてもシステムを使いこなすビジネスプロセスがなければ経営課題は解決できないだろう。

概念モデリングの留意点

◆概念モデリングの選択

 本稿で紹介したように概念モデリング手法はたくさん提案されている。たとえばオブジェクト指向方法論については、UMLで表記法としての図式言語がOMGで標準化されてはいるが、UMLを構成する図式は複数あり、すべての図を用いる必要があるわけではない。どの図を適用するかはプロジェクトや開発対象システムごとに選択する必要がある。またオブジェクト指向モデルが、他のモデルよりもあらゆる場合に優れているとは必ずしもいえない。いまのところ「他を差し置いて一つの表記法がより優れているという主張を支援する実証的証拠はほとんどない」(SWEBOK)[3]ということである。したがって、どの概念モデリングを使うか、あるいは複数の概念モデリングを組み合わせるかについては、開発対象システムごとに選択する必要がある。
 たとえば、当社が開発した「MOYA」では、現状分析、ステークホルダ分析、課題分析、ゴール分析、ビジネスのモデル化、システム要求仕様化の準備という6つの段階により要求仕様を確定していく[4]。ステークホルダ分析では関係者の持つ課題を自由に列挙して、関係者と課題間の関係を明らかにする。課題分析ではCATWOE分析[5]により課題間の関係を明らかにする。ここで、CATWOEというのは、C:顧客、A:実行者、T:変換過程、W:世界観、O:システムの所有者、E:環境上の制約のことである。変換過程では望ましくない課題を入力とし、望ましい出力としての課題に変換する。このようにCATWOE分析では課題に対するCATWOEの要素とそれらの関係を明確にするのである。ゴール分析では、CATWOE分析で抽出された変換過程の対象をゴール要求として、非機能要求間の関係を明らかにする。ビジネスのモデル化ではUMLを用いてユースケースやビジネスプロセスなどを分析する。

◆要求抽出と要求分析における概念モデリング

 従来の要求分析手法では、明確に定式化された概念モデリング手法を用いることにより要求を可視化し、分析作業の品質と生産性を向上することを目的にしていた。しかし、概念モデリング手法だけではなく、ここで紹介したように、要求の分類や優先順位を活用する必要がある。
 要求抽出でも紹介したゴール分析やユースケース分析は、要求の構成要素間の関係を明確化できるので、概念モデリング手法としても用いることができる。この逆にデータフローモデルや概念データモデルを要求抽出にも適用できる。要求抽出と要求分析の違いは、前者が現状の問題と目標の明確化にあるのに対して、後者は明確化された要求に対する競合の検出や解消にあることである。

◆要求分析の品質

 要求分析ができたときには、必要な要求が優先順位付けられ、それらの構成要素間の関係を表現する概念モデルが作成されていることになる。
 必要な要求が分析できていることと、それが妥当であることをどうやって保証するのだろうか?このような要求分析結果の品質を保証するためには基準が必要だ。前述した要求分析結果の妥当性を確認するための5つの基準もまた、要求分析プロセスに対する要求であり、非機能要求のひとつだ。このような基準のうち一貫性や完全性は当然だが、必要性や冗長性は必ずしも答えがひとつには決められないかもしれない。したがって、関係者と分析者が作成された要求について合意できるかどうかを判断基準にすることも必要である。
 次回は、要求の妥当性確認について紹介する予定である。

参考文献

[1]山本修一郎、要求工学、ビジネスコミュニケーション、http://www.bcm.co.jp/

[2]Kotonya, G. and Sommerville,, I.,Requirements Engineering ? Process and Techniques, John Wiley & Sons,2002.

[3]松本吉弘監訳、ソフトウェアエンジニアリング基礎知識体系-SWEBOK-、オーム社、2003.

[4]浜口友一、IT 投資効果を高める「ITケイパビリティ」と「要求工学」、ダイヤモンドハーバードビジネス、pp.124-125, April, 2005.

[5]木島恭一監訳、ソフト戦略思考、日刊工業新聞社、1992.



















Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved