※以下の内容はあくまで個人の考えです。世間一般で正しいかどうかは知りません。
■要件定義書に必要な要素
・要件の一覧
まず何よりもこれ。顧客(ユーザの意味も含め)から挙がった要望がメイン。
どういった要件があったのか、見返せる必要があります。
（言った言わないを避ける為）
ベンダ側から提案するシステム化にまつわる課題も有りえます。
課題は切り出して一覧化する事も多いです。
・各要件の実現方式案と費用感
挙がった要件のシステム化を実現する為の手法。
複数ある場合も多々ある為、方式の比較検討を実施します。
費用については、「高額」「安価に抑えられる」の様なふんわりした言葉は×。
標準提供価格や過去事例等をベースに万円単位（対象システムの規模により変動）程度の概算。
金額は比較検討時の大きな要素です。
・システムやネットワーク等インフラ構成のイメージ
要件定義時点では「構成図」まで落とし込むのは無理です（後に続く基本設計でやる事です）。
だからといってシステム処理の流れやサーバ間通信の方法などを言葉で表現しても分かりにくいので、
言った言わないを含め認識の齟齬を避ける為にも大まかなイメージ図が必要です。
・タスクの公開と分担
どんなタスクがあって、顧客に何を求めるか、それが遅れるとどのように影響するか。
この辺りを共有しておく事はとても大事だと思います。
要件定義ならではのものではなく、プロジェクト一般に求められる要素ですね。
・一般的な非機能要件についての検討資料
この部分はネットを探せばいくらでも転がってると思います。
信頼性、可用性、性能、バックアップ、運用、あたりでしょうか。
代替業務手段はあるか、システム利用時間帯は何時か、同時処理数の想定は幾らか、バックアップが必要なデータは何か、定期的に必要な運用操作が無いか、etc...
新規システムの場合、運用については未知数の部分が多く悩みそうですね。
基本設計や詳細設計、システムテストでの実績から具体性を持たせて設計していくのもアリでしょう。
■要件定義のススメ方
①ヒアリング
顧客要件を洗い出し、システム化方式案を検討して、どのようにシステム化するかを定義する。
という作業の中身から考えれば当然ですが、ヒアリングからスタートです。
一般的な非機能要件であればヒアリングシートを事前に用意できるので、記入依頼するのもアリ。
ただ、顧客は現業遂行しながらなので、メールだけﾎﾟﾝと送ってもなかなか相手してくれなかったりします。
初期タスクの分担については、早い段階で一度打合せ開催するのが良いでしょう。
②実現案検討
これがベンダの腕の見せ所。知識が問われる部分です。
また、要件間の整合性や制限事項にも注意が必要な為、経験が活きる部分でもあります。
例えば、ある要件の最善策が、別要件の制約事項に抵触する場合があったりします。
そのため、各案を急いで確定する必要はないと思いますが、顧客のイメージをブラッシュアップしていく為に、ある程度の塊・間隔で説明会など内容共有の場を設けるのがよいでしょう。
検討中に顧客から情報を引き出す必要性（端的に言えば質問）が生じる事も多々あります。
都度質問にするか、質疑内容をまとめておいて質問会を設けるか、やり方は様々です。
どちらもメリット・デメリットがありますし、顧客の好みもあるでしょう。
進め方については顧客と相談して合意するのが定番かと思います。
③レビューと承認
全体が出揃って整合性などを確認した上で、内容を顧客へ説明し承認頂きます。
全部をまとめて一度に、というのは時間的にも難しいと思いますので、小さな単位での承認を何度も繰り返す事になると思います。
実現方式の案毎、各要件のカテゴリ毎、ドキュメントの章立て毎など、いろんな単位が考えられます。
④要件定義内容の整理
取り決めがキチンと資料としてまとめられている事が最低要件です。
ドキュメントレビューの形で承認を得たのであれば、体裁は完成しているでしょう。
また、要件の一覧に最終結論を反映しておく必要もあると思います。
（検討結果で要件から外れる事も結構な割合で起こりますし、やる筈と思ってたという認識の齟齬も同じくらいの割合で起こります）
それに加えて、基本設計時に必要な情報にアクセスしやすいよう、インデックスを作成しておくのもオススメです。
要件の発生はいつもカテゴリ単位に纏まってる訳でもありませんが、設計はカテゴリ単位に行うのが一般的だと思いますので、識別情報があると便利です。
「あの話結論どうなったっけ」みたいな内容を探し回らなくて済むよう、状況もまとめておくとよいでしょう。
今週は会議や調査ばかりで技術的な業務があまり発生しませんでしたので、思いつくままに書いてみました。
正直大した経験はないので、甘い部分や間違いもあるかも知れません…