ユーザは、ベンダに「やりたい事」を伝える。
ベンダは、ユーザに「やれる／やれない」を回答する。
さて、ユーザは期待している内容を得ているのか？
ほとんどは想定できる内容（過去のドキュメントの使いまわし？）を、
専門用語で難解にし、体裁をキレイに整えたレポートなのでは・・・・
ユーザが求めているのは、
理解不能な専門用語で構成された「やれない」理由や言い訳
根拠のない「やれる」アピールではなく・・・
単純明快な「やれない」理由
あるいは、根拠のある「やれる」説明
それと、、、
「あえてやる」や「あえてやらない」の提案を期待していると思う。
要件とは、ユーザが本来やりとげたい目的（ゴール）であり
仕様とは、それを実現するための仕組み（プロセス）である。
システム開発のプロジェクトを進めていくと
ある時期、要件と仕様が混乱する時期がある。
それは、システム要件定義ー＞基本設計ー＞詳細設計の時期である。
ユーザ主導から開発ベンダ主導に移る工程において
ユーザがみずからの要件に自信が持てなくなってくる。
つまり、開発ベンダが言っていることが正しく思えてきて
結果的に、仕様＞要件（要件が仕様にのみ込まれる）となってしまう事がある。
あたりまえだが、ユーザはゴールの妄想はできるが
ゴールまでのプロセスを詳細に想定はできない。
それはベンダに相談せざるを得ないが
ベンダはユーザの気持ちになって回答したりしない。
ベンダはベンダの気持ちでユーザの相談に答える。
とにかく、ユーザにとって 仕様＞要件 というのは本末転倒である。
あくまでも 要件＞仕様 で、あるべき。
どんなに優秀なベンダであっても、ユーザ要件を実現する為の仕様であり
ベンダの仕様（ベンダがやりたいこと、やれること）にユーザ要件が左右されるべきではない。
※ASPやパッケージ製品などはこの限りではないが・・・
