業務フローと並んで重要な業務要求のアウトプットが，業務基本要求とユーザー要望の二つである。少々ややこしいので，まずこの二つの違いを明確にしておこう。既存のシステムを再構築する場合の方がその違いが分かりやすい。
業務基本要求：業務を行うに当たり，システムが提供する基本的な機能。別の言い方をすれば，現行システムから新システムにそのまま受け継がれるべき仕様。今当たり前にできている仕様
ユーザー要望：現行システムに対する不満や不足に関してユーザーが改善や追加を望んでいる機能。現行システムから新システムに移行するときに改良すべき，または新しく作成されるべき仕様。今はない仕様
全くの新規開発や，小さなスタンドアローンのシステムをいくつか統合して別の新システムを作る場合などは，極論を言えば業務基本要求とユーザー要望は同じであり，業務基本要求として一本化してよいだろう。
業務基本要求とユーザー要望のそれぞれについて，ガソリンスタンド会社における車検予約管理システムの再構築を想定して例を挙げてみよう。
［業務基本要求］
・新規取引時に顧客情報が登録できること
・既存顧客に関しては，顧客名，顧客番号，車両番号のいずれかで検索できること
・予約状況の照会ができること
・予約状況一覧が出力できること
［ユーザー要望］
・現在の予約状況照会は表形式で見にくいので，カレンダー表示にしてほしい
・車検予約の前に事前点検の予約も受け付けられる機能が必要である。現在は事前点検予約をExcelで別途管理している。
・顧客名のフィールドでは自動的に全角入力になるようにしてほしい
上記の例を比較してみると気が付くと思うが，業務基本要求は現在当たり前にできている機能なので，「～できること」という表現がマッチする。逆にユーザー要望は，今はできないことなので「～ほしい」ということになる。要求をざっと洗い出した時に，現在の状況を踏まえて表現した場合に，どちらの語尾がしっくりくるかという観点で分類するのも一つのコツである。
特徴的な業務は模式図で説明する
業務基本要求とユーザー要望は，一覧表の形式で提示する場合が多いが，要求にせよ要望にせよ，文書だけでは分かりにくい機能（仕様）がどうしても出てくることがある。
特に，そのユーザー企業固有の業務や仕事の方法など，一般的ではなくそのシステム特有の要求というのは，文書だけでは正確に伝わらない可能性がある。「これはあまりヨソではやっていないだろうな」と思われる業務は関しては，業務フローと業務基本要求，ユーザー要望に加えて，特徴的な部分の説明図を作成することを推奨したい。
例えば，今回のモデルとなっているガソリンスタンドでは「ミラーリング」という業務がある。「ミラーリング」というのは車検の販促活動の一つで，スーパーマーケットなどの大規模な駐車場で，ドアミラーに輪ゴムで車検セールスのチラシをかけることをいう。このミラーリングが実際にどのように実施され，その実績がどのようにシステムで管理すべきなのかを熟知しているSEはあまりいないはずだ（普通SEはミラーリングと聞けばDBの二重化を想像するだろう）。
このような特徴的な業務や処理に関しては，模式図による説明図を作ることで，要求が正確に伝わりやすくなる。模式図の書き方の例を図5で示す。ただし，この例にこだわることはない。システム開発の上流工程の参考書がたくさん出ているので，その中で気に入ったものを参考に工夫すればよい。例えば，Microsoft Project Users Forum（MPUF）が公開している「簡単！RFPテンプレート」の「業務環境図」などを参考にしてみるとよいだろう。
