システムの受託開発では必ず作成するのが要件定義書です。

要件定義書とは？

一般的にシステムで実現する範囲を決めるためのものです。顧客からの要求事項を受けて作成します。要件定義が完了すると、見積もりができるようになります。

要件とは何か？

システムで実現すること、あるいは実現しないことを示したのが要件です。システムが使われる条件を示した業務要件、システムでできることを示した機能要件、システムの品質を決める非機能要件があります。

機能要件が満たされないと、業務／サービスができないことになります。非機能要件が満たされないと、業務／サービスが満足にできない、もしくは、目標の効果が得られないことになります。

要件定義では業務フローを書くことが多いですが、この段階で書く業務フローは前提条件を書くという意味合いになるでしょう。

業務フローは要件定義の前の要求分析で明らかになっているべきだからです。とはいえ、他の要件を決める段階で改めて見直し、修正が必要になることもあります。そうして修正された他の要件と整合のとれた業務要件を作成します。

顧客の要求事項に基づき、機能を定義します。画面やデータなど、詳細に決める必要があることも多いでしょう。顧客との齟齬がなくなるまでレビューを重ねる必要があります。

実現したい業務量といった要求から、法律、システムの制限、コストといった制約を元に決めていきます。通常、アーキテクチャー設計が必要になるでしょう。実際にシステムを仮組して検証することもあります。

対象とする業務のドメイン知識があまりない場合、非機能要件の設定がうまくできない場合があります。その場合、品質特性のマップを使って整理するとよいと思います。 https://www.ipa.go.jp/archive/files/000065866.pdf

経済産業省のSLAガイドラインも参考になるでしょう。 SaaS向けSLAガイドライン（METI/経済産業省）

例えば、狙っている業務量を処理できるのか？狙っているCV数が達成できるのか？など、非機能要件によって、目標が達成できるかどうかが決まります。

非機能要件を決める際には、システム導入後に達成する目標を明確にし、目標が達成できるかどうかを検証しながら決めることが必要です。

基本設計との境界が曖昧になる部分ですが、もし要件定義の目的が見積もりであれば、見積もり上変化がない部分については、基本設計に回してもよいでしょう。

そうでなければ、基本的には、基本設計同様に詳細に決めると考えてよいと思います。

要件定義が完了しても、それで要件が固まったかというとそうではありません。その後のどの工程であっても要件は変更される可能性があります。変更される可能性があるというより、確実に変更される、と言った方が実態と合っているかもしれません。

要件の変更への対処は、QCDのいずれかの変更でしかできません。つまり、他の要件を削減するか、コストを増やすか、スケジュールを延ばすかです。外部委託している場合には、原価を下げて工数を確保するという手段が取れることもあります。

いずれにしろ、要件の変更に対処するには、これらが可能な契約でプロジェクトを開始しなければならないということです。そうでなかった場合、待っているのは顧客の損失か、受注側の損失か、プロジェクトの失敗です。

そのリスクを低減するために一般的に取られる方法は、プロジェクトバッファの確保でしょう。

特に見積もりが目的の要件定義の場合は、プロジェクトバッファを考慮した要件定義をする必要があります。後々変更される可能性のある要件については、工数を多めに積めるような要件定義をしたり、要件をできるだけ削ったりといった方法があります。

すでに見積もりが確定している要件定義の場合は、要件をできるだけ削り、プロジェクトバッファを確保する必要があります。