日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（Data Oriented Approach）型の要求定義手法を解説する。DOAはあらゆるプロジェクトに応用できる基本的なアプローチである。

　「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。

　本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範囲）を早い段階で明確にし，新システムに対する要求仕様を確かなものにしたうえでユーザーと合意しておくことが最重要である。しかし実際には先を急ぐあまり，これが行われないまま，あるいは，どのように要件を決めていけばよいか分からないまま，開発を進めてしまうことが多い。これでは冒頭に挙げたような状況はいつまでたってもなくならない。

　要求仕様を確かなものにするための実践的な要件定義の進め方を，多くのシステム開発で実績を持つ日本IBMの「IBM-DOA（Data Oriented Approach，データ中心型アプローチ）」に基づいて説明する。

必然的に生まれたDOA

　DOAという言葉は，システム開発に携わるエンジニアなら一度は聞いたことがあるだろう。DOAは，もともとクリス・ゲイン／トリッシュ・サーソンの著書「Structured Systems Analysis」（1977年）と，ロングセラーになったトム・デマルコの著書「Structured Analysis and System Specification（構造化分析とシステム仕様）」（1978年）に端を発する考え方である。ちなみにDOAという用語は，1980年代の初めに提案された“和製英語”なので，欧米のITエンジニアにはそのままでは通じにくい。

　DOAは，システム開発の重点がデータベース設計に移行した時代の流れに対応する形で，必然的に生まれた考え方である。

　DOA以前は，「このシステムは，販売，仕入，在庫管理，顧客サービスを含む営業業務を対象とする」，「販売業務には受注，集荷，納品，請求の機能が含まれる」といったように，単に機能名称を羅列したり文章で記述していた。しかし，システム化の対象となる業務の種類が増えその規模が巨大になるに従い，こうした方法では業務の本質的な仕組みや体系を「仕様（Specification）」レベルで十分に表現できなくなった。

　これに対してDOAでは，対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進める。具体的には，業務全体をデータの流れに着目して図で表現するDFD（Data Flow Diagram），データ項目の集まり（エンティティ）とエンティティ間の関連を図で表現するER図（Entity-Relationship Diagram），データの正規化，複合設計／構造化設計などの手法を組み合わせる。