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

ホーム >  要求工学 >  2011年11月号 > アーキテクチャ設計のための要求定義

国立大学法人 名古屋大学 情報連携統括本部　情報戦略室　教授
（前NTTデータ フェロー　システム科学研究所長）山本 修一郎

これまで本連載では、要求とアーキテクチャについて、２回にわたって紹介した。アーキテクチャ記述言語（連載第60回）と、非機能要求を用いたアーキテクチャ設計の評価（連載第76回）である。今回は、アーキテクチャ設計のための要求定義プロセスを紹介する。

要求定義は、それ自体で完結するプロセスではない。その後に続くアーキテクチャ設計が実行できなければ意味がない。したがって、アーキテクチャ設計を前提とした要求定義活動が必要になる。

注目されるアーキテクチャと要求の関係

最近、カーネギーメロンのSEIがアーキテクチャ中心工学ACE（Architecture-Centric Engineering）を提唱している[3]。ACEでは、ビジネスゴールに着目してアーキテクチャを設計してシステムを開発する。このプロセスで、アーキテクチャがビジネスゴールを満たすことと、システムがアーキテクチャ設計に適合することを確認する。つまり、ビジネスゴール、アーキテクチャ、システムの相互関係を確認しながら反復的にシステムを開発する方法論がACEである。ACEは、これまでのSEIの活動を集大成する実践的な取組みでもある。ここで注目すべき点は、ビジネスゴールを分析することとアーキテクチャ設計を関係付けていることである。本連載でもゴール指向要求工学について繰り返し紹介してきたが、ACEでもゴール指向要求工学を取り入れている。

またTOGAFでは、エンタープライズ・アーキテクチャを実現するためのADF（Architecture Development Framework）が中心で、要求管理になっている[4]。

そこで今回は、アーキテクチャ設計を前提とする要求定義プロセスについて、EelesとCrippsによる書籍[5]から要求定義プロセスのポイントを紹介する。

ところで、インターネットで「Architecture Centric Engineering」を検索したら、文献[6]がヒットした。やはりACE（Architecture Centric Engineering）という名称でソフトウェア工学研究会の資料だった。内容をみると、顧客要求に基づいてアーキテクチャを設計する手法である。しかし、SEIのACEのような包括的なエンジニアリング方法論ではないので注意しておく。SEIのACEのAとCの間にハイフンがあるが、日本のACEには、AとCの間にハイフンはない。日本のACEが先にあったからハイフンを入れたのかもしれないが、日本のACEにも先見性があったといえる。

要求定義プロセス

EelesとCrippsによるアーキテクチャ設計のための要求定義プロセスを、要求定義の内部と外部ならびに、要求の識別と定義の観点から４象限に分類してみると、図１のようになる。

要求の外部では、ステークホルダから要求を抽出して識別する要求準備プロセスと、定義された要求をステークホルダに定義して妥当性を確認する要求確認プロセスがある。このように外部としたのは、要求定義から見て、外側にいるステークホルダとの相互作用が必要だからである。そういう意味では、外部ではなく、ステークホルダとしたほうが良かったかもしれないが、長くなるので外部としたのである。

要求の内部では、機能要求と非機能要求を識別して優先順位を設定する要求一覧プロセスと、詳細に機能要求と非機能要求を定義する要求定義プロセスがある。

これらの要求準備、要求一覧、要求定義、要求確認のプロセスを反復的に実施することにより、要求を段階的に具体化することになる。

ここでEelesとCrippsは、ステークホルダが提示するのは要望（Requests）であって、要求（Requirements）ではないと述べている。日本では、要求と要件を区別しているように、ステークホルダがシステムに期待することと、システムの仕様として定義されることには差異があるということだと解釈できる。同書を読んだ限りでは、ややこしい話だが、彼らの要望が要求であり、要求が要件だと理解してよい。

要求定義活動の生産物

EelesとCrippsらの要求定義活動には、図２に示すような入力と出力がある。要求定義活動への入力情報としては、ビジネス実体モデル、ビジネスプロセスモデル、ビジネスルール、EA（エンタープライズ・アーキテクチャ）方針、既存IT環境、ビジョンがある。ビジネス実体モデルでは、ビジネス領域の基本概念を定義する。ビジネスプロセスモデルでは、ビジネスによって実施される活動と、その役割を記述する。EA方針では、アーキテクチャを作成するために組織レベルで必要なルールとガイドラインを記述する。既存IT環境では、開発対象システムの制約条件となる既存のIT環境を定義する。ビジョンでは、ステークホルダから見たシステムのビュウを定義する。これらの情報がないと要求定義活動に着手できないのである。

要求定義活動からの出力情報には、機能要求、用語集、非機能要求、優先順位付き要求一覧、レビュ記録、ソフトウェアアーキテクチャ、ステークホルダ要望、システムコンテクストがある。ステークホルダ要望が要求定義活動の入力ではなく出力となっているのは、この活動によってステークホルダから要望を聞き出して明確にするためである。

続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話（03-3507-0560）でも承っております。