Column

「要件定義書」とはSEによって書かれる最終書類である。

システム開発に関して顧客からの要求を受けた後、システムを実際に作る前に提出される最終的な書類のことで、「開発されるシステム内容」について書かれています。 そのため「要件定義書」は、システム開発をするシステム開発者（SE）によって書かれるのが主流です。

専門知識を使いながら開発されるシステムの内容を確認して、そのシステムの持つ機能や性能を定義していき、最終的に定義された機能や性能のこと、またはそれらを定義することを「要件定義」と言います。

システム開発者からシステム開発のプランをまとめて、専門的な知識のない（少ない）顧客に対してもわかりやすく説明すること。

「必須要件」「希望要件」を明確にすること。 業務フローの詳細を把握し、実装すべき機能範囲を顧客とすり合わせて合意を得ること。

最終的なシステムのゴールを明確化させること。

ユーザーがそのシステムに求めるものを明確にすることができ

「そのシステムで何がしたいのか」

「なぜそのシステムが必要なのか」

なるべく具体的に想像し、定義することができる ユーザーサイドと開発サイドの間で十分に話し合い、システムに期待すること、役割、目的の情報を共有化し、しっかりとした認識の統一、相互理解を深めてからシステムの開発に進むことができる。

開発サイドは要求の理解に基づき、システムの目的に沿った機能や性能を要件として定義する 要件定義ではプロジェクトの目的を明確にし、ユーザー、開発両者の意識を統一することでシステム開発における失敗の原因（「認識の不一致」「目的のブレ」などから起きる仕様変更や追加）を抑制し、プロジェクトを成功へ導く。

業務フローを作成しシステム導入後の業務の流れを記述

業務要件は要件定義の初期に実施する工程です。

システム化する前に現状の業務がどのように流れているかを確認し、問題を抽出した上で、新たに何を実現すべきかを決めていきます。

この段階ではシステムは意識せず、あくまで業務そのものに焦点を当てます。

業務要件では業務に詳しい担当者に参加してもらい、密度の高いコミュニケーションを図ることが大切です。 もし発注者と開発者の目的が噛み合わないまま開発がスタートしてしまうと、大幅な手戻りが発生して時間とコストの浪費につながります。

どのようにシステム化するかを記述

業務要件で現状の業務分析と新たな業務の流れを定義した後は、それをどのようにシステムに落とし込んでいくかを決めます。

ここで決められる、システム開発の方向性をシステム要件と呼びます。 業務要件と大きな違いがないように見えますが、実際には業務要件で決めた「業務上の要望」と、システム要件で決める「システム化を通じてできること」は必ずしも同じではないため注意が必要です。

例えば業務要件が「このエリアにある取引先を調べたい」だとしましょう。

これに対するシステム要件は、「PCからブラウザ経由で検索できること」や「スマホアプリを作成し検索できるようにする」などの手段になります。

このシステムができる機能を記述

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。

機能要件はシステム開発を通して最低限実現すべき機能です。 機能要件は発注者にヒアリングなど、具体的に確認しながら検討していくと必須要件か希望要件かの切り分けがしやすくなります。

また、機能要件の成果物は、後述の非機能要件と合わせて、後続の基本設計フェーズでの重要なインプットとなります。

機能以外の要件を記述

機能要件はシステム開発において必須の機能なのに対して、非機能要件は”機能以外”でエンドユーザーがシステムに求める要件のことです。

非機能要件は実現すればするほどクライアントの満足度を上げることができます。

例えば「一覧画面からマイページ画面に画面が切り替わること」は機能要求ですが、「3秒以内に切り替わること」は非機能要求となります。

他にもデザインや、セキュリティなども非機能要件となります。

非機能要求の定義に漏れや誤りがあると、仕様が変更や追加となりコストや時間がかかることになります。

そのような事態を避けるためにも、非機能要求を網羅的に確認し、プロジェクトが見逃してしまった暗黙の要求としてしまわないことが重要です。