システム要件定義書とは?必要な項目や書き方を徹底解説

システム要件定義書とは?必要な項目や書き方を徹底解説

システムの最終成果物に、しっかりシステムの内容が詰まった要件定義書は欠かせません。言い換えれば、的確にポイントを押さえた要件定義書がなければ、プロジェクトを成功させることができないとも言えます。
今回は、そんな要件定義書を最終成果物に仕上げていくために押さえておかなければならない「要件定義の項目」とその理由についてご紹介します。

要件定義書とは?

要件定義書とは、システム開発やアプリ開発などの際にクライアント(発注者)の要望を開発会社がヒアリングし、要望を実現するための機能や画面イメージなどを文書にまとめたものです。クライアントに提出し、確認してもらうことで、クライアントの要望を明確化し、システムやアプリの完成イメージをすり合わせることが目的。要件定義書は、システムやアプリに詳しくない人でも理解でき、クライアントと開発会社が共通の完成イメージを描けるものでなくてはなりません。要件定義書をもとに、システムやアプリの基本設計、詳細設計が進められます。

要件定義書を作成する目的

要件定義とは、お客様の要望を具体化し、実際にシステムを導入するまでの準備を進めるための工程のことです。要件定義の成果物は「要件定義書」と呼ばれるもので、これを基にシステムの設計工程へと進めることができます。
プロジェクトの初動の段階で作成し、最終的な成果物は、この要件定義書に沿った形で完成しますので、システム開発を行う上で最も重要な項目とも言えるでしょう。

要件定義を行う流れとしては、既存のシステムの設計や業務フローの把握やお客様へのヒアリングなどの現状把握を行う作業から始まり、要件を整理/解析、さらに実際にプロジェクトの進行の流れ、役割分担、成果物の具体的なイメージの作成までのステップを経て、最終的にWordやPowerPoint、Excelなどのファイルにテキスト、図解を用いて要件定義書としての成果物に仕上げていきます。

この要件定義書を作成する上で、最も重要なポイントとしては、現状把握です。
「今はどうなっているのか」、「今後はどのようにしたい」といった要望が、実際に入力する項目や出力される項目、処理時間に代わり、最終的なシステムとしての良し悪しを決めます。

プロジェクトを進めてしまう前に、何度もミーティングを重ね、お互いに納得するまで要件定義を煮詰めるようにしましょう。

要件定義書の書き方|要件定義の工程

発注者の要求をヒアリングする

要件定義は、クライアントの要求をヒアリングすることからスタートします。どのような課題を抱えているのか、どのような解決策を望んでいるのかなどを明確にしていきます。ただし、クライアントが課題を明確に言語化できるとは限りません。業界動向、発注企業が置かれている環境、社内事情などをできる限り把握し、クライアントが言葉にできていない部分を捉える事が重要になることもあります。

要求内容をシステムで解決できるか検討する

ヒアリングで明確にしたクライアントの要求を細分化し、どうすればシステムで実現できるかを検討します。課題解決・目標実現に必要な手順を、システムで実現できるレベルにまで細分化し、必要な機能を洗い出していくプロセスです。時間・コストなどによっては、実現不可能なことが出てくる可能性があります。そうした点も明確にし、次のフェーズでの開発や代替案を提案する準備を進めます。

発注者との打ち合わせを踏まえて要件定義書を作成

ヒアリングと社内での検討を踏まえて、要件定義書にまとめていきます。解決すべき課題、目標、システムの全体的な構成、具体的な機能、画面イメージなど、これから開発していくシステムの完成イメージをクライアントとズレなく、共有できるようにします。さらにシステム以外のセキュリティや保守・運用についても明確にします。

要件定義の成果物に盛り込むべき項目

最終的に要件定義書の成果物に盛り込むべき項目は多岐に渡りますが、主な項目としては以下のようなものがあります。

システム概要や背景・目的など

システムを導入する理由や背景、またこのシステムの概要や範囲などについて表記します。現状を具体的にまとめることで、実際のプロジェクトを進める上での共通見解をプロジェクトメンバーと共有することができます。このようにすることで、プロジェクトに支障をきたすような見解の相違が生まれないようにすることができるため、成果物には必ず含めるようにしましょう。

システム導入の目標やメリット

現状から導きだした答え、目指すべきシステム像を決めます。このシステムを導入することによってプラスとなる面や、目標などを実際に表記します。(作業工数20%削減、○○の工程が一括して処理できるなど)

システムの機能、入出力要求

このシステムでできる具体的な機能はもちろん、客先から要求されている機能を詳細に表記します。また、どのような項目が入力できるのか、制限はついているのか、出力できる項目や連携できるソフトウェア、印刷できる内容などを表記します。成果物として仕上げる際には、文章ではわかりづらいので、画像などを入れてイメージしやすいようにすると良いでしょう。

導入後の業務フロー

システムを導入することにより仕事の流れが変わることがあるので、変更点などをフロー表記します。各項目の入力作業、使用者に違いが出る場合は、クライアントの体制を合わせてフローチャートを作成するとよりイメージがしやすくなるでしょう。

システム要求

ハードやソフトウェアの構成、対応や連携しているOSなどのシステム面、拡張性などについても表記すると良いでしょう。システムの保守管理、引継ぎを行う上でもこのシステム要求が重要な項目となります。また、クライアントサイドのシステムエンジニアとの連携にも不可欠な要素と言えるでしょう。概要だけでなく、バージョンなどの細かな要素に関しても項目立てて、簡潔に記載するようにしましょう。

性能や品質要求

機能だけではなく、処理速度や処理能力が客先の要望を満たしている必要があります。具体的な時間や数字などを出して、客先からの品質要求に応えられるように表記しましょう。
稀にクライアントがシステムに関する知識に乏しい場合もあります。このような状況の場合は、処理速度や処理能力について、クライアントがイメージしやすい単位などで記載することが望ましいです。

セキュリティ要求

最近では情報漏洩やウイルス感染などによる被害も多発していますので、セキュリティ面に関する記載も重要です。まずは、主な攻撃手法を把握し、それぞれのパターンに対して、対応できるシステムにするための項目を列挙しましょう。
また、OWASP Japanなどでは、セキュリティ要件定義書の配布なども行っていますので、こちらなども参考にセキュリティに関する内容も成果物に含めるようにしましょう。
【参考】Webシステム/Webアプリケーション セキュリティ要件書1.0

これらは大きい題目として記載し、この中に詳細を小項目として盛り込んでいきます。できるだけ具体的に記入した要件定義書を作成することで、双方の誤解をなくし、スムーズに設計工程へと進めることができるでしょう。

要件定義書をより良い成果物に仕上げるためのポイント

要件定義書をより良いものに仕上げるには、どのような点に注意すれば良いのでしょうか。ポイントは「わかりやすさ」にあります。客先のスタッフは誰もがエンジニアほど知識を持っているわけではありません。部署によってはITの知識はあまりないといった人もいますから、わかりやすい内容にするように心掛けましょう。

わかりやすい要件定義書の構成

「大項目」、「小項目」と言ったように、内容をグループ分けし、わかりやすい要件定義書の構成にします。このようにすることで、見やすくわかりやすくなるのはもちろん、探したい項目を見つけやすくすることもできます。

使用者がわかりやすい文章

専門用語の後には解説を入れたり、少し噛み砕いた表現を用いたりすることで、実際の使用者がわかりやすいような文章にすることが大切です。

図解表現を用いる

例えば入力画面や出力画面など、文章では表現しづらい部分については図解を用いることで、内容がイメージしやすくなります。

いかがでしょうか。上記の内容を参考に要件定義を最終的な成果物に仕上げてください。

要件定義書はシステム開発のスタート地点

要件定義書はシステム開発のスタート地点であり、その先の作業の基礎となるものです。クライアントの課題を明確にし、その解決手段となるシステムの完成イメージをクライアントと共有するためのドキュメントであり、システム開発後の「目指すべき姿」「あるべき姿」をクライアントとともに描いていくものといえます。課題を正確に捉えることと同時に、クライアントの立場・視点に立ち、ときに言葉の裏にある言語化されていない課題を見出すことが重要になります。

求人詳細ページへのリンク

職種関連カテゴリ

システム要件定義書とは?必要な項目や書き方を徹底解説のページです。ITエンジニア・移動体通信エンジニア(技術者)の派遣求人ならブレーンゲート。株式会社ブレーンネットはシステムエンジニアやネットワークエンジニア、プログラマーの派遣・転職をサポートいたします。