情報システムの要件を検討するときには、２つの視点から検討する必要があります。
- トップダウンの視点（経営者の視点）
- 個別システムは、経営戦略や情報化戦略を実現するものですから、それらの方針に従って開発されるべきです。
- ボトムアップの視点（利用現場の視点）
- 利用部門は、現行の業務の仕方あるいは既存の情報システムに不都合な点や改善すべき点をもっています。それを解決する必要があります。基幹業務系システムは業務の仕方を規制します。そのため、業務に合致していること、利用者が使いやすいことが要求されます。
情報化戦略（情報化計画）では、基本的な方針は定めていますが、個々のデータの入力方法、出力帳票の体裁、操作の方法などの詳細や非機能要件まで決めるのは無理です。ところが、利用者にとっては、その詳細が重要なのです。
しかも、トップダウンとボトムアップの間に矛盾がある場合もあります。利用部門が経営戦略や情報化戦略を理解していない場合もありますし、それらの戦略が現場の実情を把握していなかったことに起因する場合もあります。その矛盾を解決しなければ、情報システムは構築できません。
要件定義は、次のように区分できます。事業要件定義と業務要件定義の一部を超上流工程、業務要件定義の一部とシステム要求定義を上流工程、ソフトウェア要件定義以降を下流工程といいます。
- 事業要件定義
- 上述のトップダウンによる要件定義です。経営者あるいはその代行者（組織）が主体になります。
- 業務要件定義
- 上述のトップダウンとボトムアップによる要件をまとめたものです。これが情報化戦略による全体計画から個別の販売システムや会計システムにブレークダウンしたものになります。
あくまでも業務の観点からの要件であり、ＷＨＡＴ（何をしたいか）を示していますが、ＨＯＷ（どのように実現するか）は示していません。情報システム開発を外注する場合にはＲＦＰ（提案依頼書）に相当します。利用部門が主体になります。 - システム要件定義
- 業務要件を提供者の観点（ＨＯＷ）から修正したものです。実際に情報システムで実現するには、業務要件では明示されていなかった事項や、具体的な情報の流れなどを検討する必要があります。
また、業務要件をそのまま情報システムの要件とするのは、現状の技術では実現性が低いこともあるし、実現に多額の費用がかかる場合もあります。安価で確実性のある代替手段を検討する必要があります。
これらの検討により、情報システムで実現すべき要件を具体的に定義したものがシステム要件定義です。一般に要件定義というとき、このシステム要求定義を指すことが多いのです。これをまとめたのが外部設計書に相当し、外注による開発では請負契約でのシステム仕様書に相当します。利用部門と提供者の共同作業になります。 - ソフトウェア要件定義
- システム要件までは業務用語で表現されていました。それを、実際にプログラムを作成したり、データベースを設計するために、ＩＴ用語に翻訳し、具体的なロジックやデータ構造などを示したものです。これをまとめたのが内部設計書に相当します。この作成は提供者が行います。