システム開発を行う上で絶対に欠かせないイベントが「要件定義」です。要件定義は案件の命運を決めるといっても過言ではないほど重要な工程になっています。当メディアではこれまでにも要件定義にフォーカスした記事を執筆していますので、重要性について改めて確認してみるのも良いでしょう。
要件定義はシステム開発において重要な工程になっているのですが、その過程で作成するドキュメントは案件を進めるための前提となり、かつゴールとなる重要書類となります。
この記事では要件定義の工程において作成しておくべきドキュメントをまとめていこうと思います。システム開発を行う上でドキュメントは大事ですが、それと同じくらい、ユーザー（発注元）においても作成するシステムを可視化できる重要にものになるので、どのドキュメントが必要になるか程度は知っておくべきかと思います。
要件定義で作成するドキュメント類
まずは要件定義のフェーズで作成するドキュメント一覧を挙げておきます。以下はサンプルになるため、一例として考えて置けばよいでしょう。以下を見てみる限りでは、いろいろなドキュメントを作成していく必要がある、という印象を受けるのではないかと思います。
- システム概要
- 全体図
- 業務要件
- システム要件
- 機能要件
- 非機能要件
とはいえ、最終的に作成するのが「要件定義書」となります。要件定義で作成するドキュメント類のサンプルはIPAのサンプルが役に立つので知っておいて損はないと思います。各ドキュメントのサンプルもあるので、実際に作業に当たる時にイメージが湧きますね。
また、上記に記載したドキュメント類一覧は「【システム開発】要件定義とは | 役割と重要性」にも記載しているため、要件定義フェーズの役割について知りたい人は、まずはコチラをチェックしておいても良いでしょう。そのほか、要件定義書のサンプルは以下が参考になります。
要件定義で作成する5つのドキュメント
先ほどの一覧を一例として、各ドキュメントの特徴を簡単に解説していきます。要件定義は様々なドキュメントを作成しながら進めていくフェーズですが、システム開発において最も重要なフェーズといっても過言ではありません。システム開発を成功に導くためには、案件の最初の工程で可能な限りドキュメントを充実して合意を得ていく必要があるのです。
システム概要・全体図
要件で定めているシステムの概要を記載するものになります。システムの全体像を記述することが多く、システムの機能や特徴、構成要素・構成図などシステムの全体像を把握するために記述するドキュメントになります。ハードウェアの構成図などもここに含まれます。
業務要件
業務要件は字のごとく、業務の要となることです。システムを作成するにあたって業務が達成するべき目的や、達成に必要な機能や条件といったものを具体的に書き出したドキュメントです。システムを利用するユーザー側の視点に立って書き出す必要のある重要なドキュメントになります。
普段のオペレーションフローや業務体制、どれぐらいの規模の人がシステムを利用するかといった、システムを導入する際に必要となる指針になります。要するにシステムを利用する側の、新システムに対するニーズ・利用状況の把握をするために必要なドキュメントです。
システム要件・機能要件
業務要件で記載された要件を達成するために、システム側が達成しなければならない内容を記載したドキュメントをシステム要件と呼んでいます。どのような機能を備えている必要があるのかを明記したものになります。業務要件がユーザー視点であるとするならば、エンジニア視点からシステムに必要な機能を書き出したドキュメントといってよいでしょう。
非機能要件
機能要件とは異なり、非機能要件というものも記述することがあります。機能要件はシステムを開発するうえで主目的となる機能のことを指しますが、非機能要件は主目的以外の機能を記したドキュメントになります。例えばユーザビリティ、性能、拡張性、セキュリティといった項目は、システムの目的以外であっても「システムのクオリティ」を高めるために必要な機能になります。
主目的を達成したとしても、使い勝手が悪かったり性能が低かったりしてしまっては開発した意味がありません。そうした状況を防ぐため、非機能要件において「システム全体の質を担保するため」に記述するべきドキュメントとして知られています。
要件定義はドキュメントが重要
要件定義のフェーズでは様々なドキュメントが必要となることを示しました。ここで改めて記述しておきますが、要件定義のフェーズでは主に以下の3つのドキュメントが特に重要となります。
- 業務要件
- 機能要件
- 非機能要件
システム概要といったドキュメントは開発を進めていく段階で変わっていく可能性があります。しかしながら、業務フローやユーザーニーズといった業務要件や、目的を達成するための機能要件、それ以外の品質を担保するための非機能要件は頻繁に変わることがありません。
システムを開発するということは、業務のボトルネックをITの力を利用して解消することであり、それがブレてしまうのはシステムを導入したとしてもボトルネックの解消に至らない可能性があります。また既存システムの刷新案件であったとしても、前システムが担っていた業務がカバーできていることは必須となります。
そうしたシステムの状況を把握して、適切なシステムの開発を進めるためにも、特に上に挙げたドキュメントは重要なはずなのです。システムは不透明なことが多く、後から問題・変更が発覚することは日常茶飯事です。そうした状況でも方針にブレがないようにするため、ドキュメントをしっかりと整備しながらフェーズを進めていくことが求められます。
