実際に情報システムを利用して業務を行い、成果をあげるのは利用部門ですから、情報システムの開発において、利用部門がはたすべき任務は多いし重要なのです。
経営戦略や情報化戦略をブレークダウンして，個別の情報システムの計画に至るまでの「超上流工程」では、対象業務を担当する利用部門が、現状の課題や将来のあるべき姿を検討して、業務の観点から情報システムへの要件を明確にすることが必要です。
そのとき，費用対効果の検討が重要です。情報システムの開発・運用にかかる費用は要件内容により大きく変わります。情報システムを活用して効果を実現するのは利用部門の責任ですから、利用部門が「○○の要件を満たした情報システムが得られるならば、○○の効果が得られることを約束する」ことを明確にする必要があります。
また、効果は情報化だけで実現できるのではなく，業務の改善や改革、場合によっては社外関係者との折衝を通して得られるものです。利用部門が責任をもってその解決しなければなりません。
業務レベルでの要件を実現するために、具体的な情報システムに対する要件へブレークダウンする段階です。利用部門，情報システム部門，ベンダなどからなるプロジェクトチームを編成して，具体的な要求事項を調査して，開発するべき仕様を外部設計書としてまとめ，経営者を含む関係者に提案して，あらためて開発の承認を得るプロセスです。
ここでは、どのような帳票が必要になるか、使いやすさはどうかといった、詳細な仕様を決定します。これらは、実際に利用する立場でないとわかりません。
ここで重要なことは、必要十分な要件にすることです。このフェーズで適切な仕様にならないと，本来の目的とは異なるシステムになって，期待する効果が得られない危険があります。逆に、過大な要件にすると費用や時間が増大します。また，このフェーズがあいまいなままに以降のフェーズに入ると，後になってから大きな手戻りが生じます。これは，開発期間や費用に大きな影響を与えます。
ソフトウェア設計やプログラミングのプロセスは、ＩＴ部門やベンダなどの提供側が主体になりますが，業務部門が中心で行うべき作業は多くあります。
例えば，得意先には得意先コードを付ける必要がありますが，コード体系は表示順序や層別など業務での利用勝手に大きな影響を与えますので，業務部門が作成しなければなりません。また，得意先コード，得意先名，住所，得意先区分など得意先台帳に記載されるような項目をマスタファイルが必要になります。これらの整備も業務部門の任務です。
これらが正確に整備されていないと，プログラムは作れませんしテストもできません。
システムは人間が作るものですから，多様な要因により誤りが生じます。その発見と修正が不十分なままに実施すると大きなトラブルにつながる危険があります。
ところが，要件定義フェーズでなかなか仕様が決まらないとか，それがあいまいなために大きな手直しが発生するなどにより，次第に納期が迫ってくると，テストフェーズにしわよせられ，テスト不十分なままに実施移行することになりがちです☆。
単体テストや結合テストなど，プログラムレベルでのテストは開発者に任せることができます。しかし，システム全体として要求した仕様通りになっているかのテスト（システムテスト）や実際に使ってみてのテスト（運用テスト）は，検収テストであり試運転ですので，発注者である業務部門が主体になって行う必要があります。
システムが出来上がり運用フェーズに入ると，システムにあわせた業務の仕方をすることが重要になります。例えば受注をしたら直ちにコンピュータ入力をすることと定められているのに，まとめて入力するほうが好都合だからといって，数日分を放置しておくと，その間の情報がコンピュータで把握できず，実際とは異なる結果を出してしまいます。新規の得意先が発生したのに放置しておけば，そことの取引データをコンピュータに入力することができません。
手作業の時代では，転記作業が多く非効率でしたが，逆にチェック機能にもなりました。ところがシステム化すると，いったんコンピュータに入ったデータは，なかなか誤りが発見できません。特にリアルタイムのシステムでは，誤ったデータが入力されたとたんに他のシステムへ影響してしまいます。誤ったデータが入らないように，システムにどのようなチェック機能を組み込むべきかは操作者が最も気づくのですから，要件定義のフェーズで提示する必要があります。