先ずは業務的な要件、次にシステム的な要件

システムの要件を決定するには

1.業務要件(システムを使って何をどうやりたいのか)
2.システム要件(どのようなシステムが欲しいのか)

の順で固める必用があります。

1.
まず発注前に業務要件を漏れなく洗出し書き出す事です。
これが無ければ方針が無いに等しく、システム要件はグラグラと
揺れ動くものになります。
体裁はどのようなものでも良く、とにかく
「第三者が理解できるよう」「細かく」「網羅的に」「具体的に」
を目指して下さい。

2.
次にシステム要件ですが大抵は発注先のSE(又はコンサルタント)から
ヒアリングを受け一緒に固めていくことになります。
可能であれば発注者側である程度纏めておくと以後の助けとなります。
この、2.では1.の内容が基盤となります。
具体的に作成するものは、ユーザの利用シーン、業務フロー、
画面・帳票イメージと部品の定義、データ項目の洗出し、
画面やサーバに必用な機能の定義 etc...です。


質問の「どうしたら要件をうまく伝えられるか」ですが
発注側にできる事は「 1.をしっかりやる」につきます。
発注側ではどうしようもないけれど重要な事は
「SEやコンサルの技量」です。
良い「SEやコンサル」に当たるかどうかは運任せという
のが現状です。私は第三者のコンサルタントを使う事を
オススメしています(その場合、業務要件とシステム要件を
合わせて協力してもらいましょう)。

発注者は、決してシステム的な知識を勉強する必要は無く、
業務要件の纏めと良いパートナー探し(開発会社や第三者コンサル)に
重点を置いて下さい。

http://labo.itsl.jp/