「目的」の軸をブラさない事が重要です

要件定義はシステム開発のキモですので、エンジニア側から見ても、ここでうまく要件を拾い出してシステム設計に落とし込めるかというのがいわば「腕の見せ所」です。

ただしシステム規模や開発手法、契約状態により、「誰が主体になって行うか?」という点まで含めて、すでに他の専門家からご意見が出ている通り、方法は色々です。

*常に目的を意識して

要件定義の流れとしては、

1.要件を伝える(書き出す)
2.システムの設計を考える(書き出す)
3.そのシステムで要件が満たせるか検討
4.必要なら修正(=1 に戻る)

を繰り返しますが、実のところ、3の細かい要件を確認時に、個々の機能がきちんと動くと「何だかこれでいいような気がする」という気がしてしまうものです。

設計をしたエンジニアの方は目的を汲み取ったつもりになっていますので、発注者の方は「このシステムで目的が達成できるか?」を、エンジニアに気後れする事なく、冷静に検討して下さい。

*シンプルな目的定義を

しかし、目的があまりにも複雑だったり多岐にわたっていると、担当者の方の判断も非常に難しく、負担になります。
プロジェクトを始める時に、誰でも自分の頭で理解できるシンプルで明確な目的を定め、それをプロジェクトメンバー全員で共有する事が大切です。

*問題は、それが重要かどうかの判断を

実際問題として、いくら伝えても多少の認識の食い違いは必ず残ります。

「思い通りでない」という点が、システムの目的からしてどの程度重要かによって、これも冷静にエンジニア(受注者)側と交渉して下さい。
あまり細かい事にこだわりすぎると、全体の進行がストップしてプロジェクトが頓挫してしまう可能性もあります。