オブジェクト指向の考え方に基づく要求定義の方法を,ラショナルソフトウェアの開発プロセス「RUP」に基づいて解説する。業務や機能をオブジェクトとして抽象化しながらシステム化要求にまとめていく手法をしっかり理解して欲しい。

 「オブジェクト指向は,システムの分析・設計やプログラミングに関する考え方のはず。そんな考え方に基づいて,業務分析を伴う要求定義ができるのか」。一緒に仕事をするITエンジニアから,しばしばこう言われることがある。

 オブジェクト指向は難しいという先入観があるため,そういう疑問が生まれるのかもしれない。そんなとき筆者は声を大にして,こう返答している。「オブジェクト指向の考え方こそが,要求定義に向いている」と。

 その1つの理由は,要求変更を管理しやすいことである。オブジェクト指向では,業務の役割やシステムの機能,情報などを意味を持つまとまり(オブジェクト)として捉えるため,オブジェクト間の関連を把握しやすい。その結果,ある要求を変更したときに,どのオブジェクトが影響を受けるのかを効率的に追跡できる。

 もう1つは,業務の流れやシステムの機能などをすべて抽象化してUMLなどの図でシンプルに表現するため,要求定義を担当するエンジニアとユーザーが互いの考えを共有しやすいことだ。

 こうした効果は,筆者が担当したオブジェクト指向開発プロジェクトの現場で実感していることである。

 オブジェクト指向に基づいた要求定義の方法論はいくつかあるが,代表格はラショナルソフトウェアの「RUP(Rational Unified Process)」だ。RUPは分析/設計や実装だけでなく,要求定義の作業分野もカバーしている。ここではRUPで定義された要求定義の方法論を解説する。

出発点はビジネスモデリング

 RUPにおける要求定義の流れを大まかに示したのが図1だ。作業が複数のプロセスに分かれており,各プロセスで成果物が規定されている。

図1●オブジェクト指向開発における要求定義の方法論の例<br>RUP(Rational Unified Process)で定義された主要な手順と成果物を示した。文書名が「~図」となっているものと「ビジネス分析モデル」以外は,基本的に文章で内容を記述する
図1●オブジェクト指向開発における要求定義の方法論の例
RUP(Rational Unified Process)で定義された主要な手順と成果物を示した。文書名が「~図」となっているものと「ビジネス分析モデル」以外は,基本的に文章で内容を記述する
[画像のクリックで拡大表示]

 全体を大きく分けると,「ビジネスモデリング」と「要求」という2つの作業分野(ワークフロー)で構成される。どちらも同じような成果物を作るのだが,焦点を当てる対象範囲(抽象度)が違う。ビジネスモデリングでは,ユーザー企業の外部にある顧客や取引先との関係を手掛かりにして,ユーザー企業における業務のあり方や部門の役割などを根本から見直す。

 こういうと,「それは経営コンサルティングの分野ではないか」と思うかもしれない。確かに,ITベンダーはビジネスモデリングに続く作業分野である要求作業から行う場合が少なくない。しかしユーザー企業の業務や部門の役割に関する理解を深める意味で,ビジネスモデリングを行う意義は大きい。実際には時間の余裕がない場合も多いが,できる限りビジネスモデリングから実施することをお勧めする。

 その後の要求作業では,システムそのものをモデリングの対象にする。ユーザー企業全体からシステムへと,焦点を絞り込むわけだ。システムを直接利用するエンドユーザーや,接続する他システムなどを手掛かりに,システムの要求を固め,最終的に「ソフトウエア要求仕様(SRS=Software Requirements Specification)」を作成する。