PR

2割以上の作業時間をかける

 要件定義に続く外部設計フェーズでは,クライアント/サーバー,インターネット/イントラネット,ホスト集中,手作業,データベース(データストア)の配置――といった新システムを実現するための物理的要件をDFD新論理モデルの上に記述した「DFD新物理モデル」を作成する(図6の(4))。外部設計では,このDFD新物理モデルに基づいてユーザーインタフェースやデータベース,プログラム構造の設計を進めていく。

 以上,日本IBMの標準的な要件定義作業を説明した。DFDを使って要件定義という抽象的な作業を“定型的な作業”にしていることがお分かりいただけただろう。このように要件定義の作業を手順化しておけば,小規模プロジェクトから大規模プロジェクトまで,汎用的に適用できる。

 最後に,筆者の経験から要件定義に関するアドバイスを述べる。それは,「要件定義には十分な時間をかけるべき」ということだ。実際,日本IBMで請け負った近年の大規模プロジェクトでは,20~25%のコスト・期間を要件定義に当てている。小規模・短納期開発であれば,30%以上を要件定義にかけてもよいだろう。

中山裕美子(なかやまゆみこ)
日本アイ・ビー・エム 技術ソフトウェア・エンジニアリング主任 ITスペシャリスト
1991年,日本アイ・ビー・エム入社。システム・エンジニアとして,システム開発プロジェクトの上流工程のリーダー/アドバイザを担当した後,現在は社内外に向けたプロジェクトマネジメントやナレッジ・マネジメントの推進を担当している


eビジネス向け要件定義の手順

 日本IBMでは,システムの規模や特性に応じて様々な手法を使い分けたり組み合わせたりしている。ここでは,オブジェクト指向分析・設計手法を取り込んだ開発プロセス「ADSG for ebusiness」における要件定義手法を簡単に紹介しておく。

 ADSG for e-businessでは,UMLを標準の表記法として使い,図Aに示すような成果物を作成する。以下,要件定義の主要な作業を説明しよう。なお,これらの作業は必ずしも順番に実施するわけではなく,相互に関連しながら成果物を洗練させていく。

図A●ADSG for e-businessにおける要件定義の主要な成果物
図A●ADSG for e-businessにおける要件定義の主要な成果物(機能要件に関する部分のみ抜粋)
[画像のクリックで拡大表示]

(1)システム化範囲の検討
 対象業務全体を鳥瞰するハイレベルなユースケース図(システム・コンテキスト図)を作成し,分析の対象範囲,開発すべき機能,アクター(システムと相互作用するユーザーや外部システム)を把握する。

(2)ドメイン・モデルの作成
 対象となるビジネス・エンティティを概念的な「クラス」として定義したクラス図を作成する(ドメイン・モデル)。最初から精緻なモデルを作る必要はなく,他の作業の分析結果に応じて順次洗練していく。

(3)ユースケース分析
 ドメイン・モデルを参照しながら,システム・コンテキスト図をブレークダウンして詳細なユースケース図(ユースケース・モデル)を作成する。

(4)画面/帳票のプロトタイピング
 新システムが扱うデータ項目を洗い出すために,画面/帳票のプロトタイプを作成する。ここでは,見映えやデザインの詳細さにはこだわらない。システムが扱うデータ項目を網羅し,大まかな画面の流れが提示できればよい。

(5)ロバストネス分析
 ドメイン・モデルとユースケース・モデルで洗い出された個々のユースケースを基に,ロバストネス図(ロバストネス・モデル)を作成する。

(6)データ要件の定義
 ドメイン・モデル,ロバストネス・モデル,画面/帳票のプロトタイプ,他システムとのインタフェース仕様などを基に,システムが取り扱うデータ項目を抽出・整理してER図を作成する。さらに属性(データ型,桁数,意味定義など)の定義や,シノニム/ホモニムの識別を行ってデータ・ディクショナリに登録する。要件定義の段階でデータ項目を識別・整理することにより,データの一貫性・整合性を確保しながら,クラス設計やデータベース設計を進めることができる。

 以上の作業に加えて,ユースケース・モデルと現行業務/システムの調査結果などを基に新システムが満たすべきパフォーマンス,セキュリティ,可用性などの性能・品質に関する要件を定義し,運用・保守,障害対策に関する要件も洗い出す。

 これらの要件とコスト面の制約を考慮しながら新システムのシステム構成(アーキテクチャ)に関する複数の代替案を検討・検証し,技術的な実現性・妥当性を検証する必要があればプロトタイピングを実施する。