「要件定義書を作成するSEは、花形SEである」と言っても、過言では有りません。それだけに、「要件定義書は大切な存在である」と言えます。
そこで今回は、要件定義書に関連する、以下の事項を解説します。
この記事でわかること
- 「要件定義書」とは何か?
- 「要件定義書」は誰がいつ作るのか?
- 「要件定義書」はどんな内容を書くのか?
要件定義書は誰がいつ作るの?
要件定義書は、基本的にはSEが作成します。しかし、規模の大きい企業や部署においては、要件定義を専門に請け負う部門や担当者も存在します。
この要件定義書は、ソフトウェア開発工程において、主に「ウォーターフォール・モデル（Waterfall Model）」では、基本的に最も早い段階で作成します。
なお、ウォーターフォール・モデルに関しては、以下の記事で詳細に解説しています。
要件定義書はどんな内容を書くの?
要件定義書は、顧客が求めるシステムを実現するために必要な情報を、過不足なく記述するものです。主に顧客へ向けて説明するための資料となります。
要件定義書は統一された書式や形式があるわけではありません。これは会社や部署ごと、場合によっては顧客から指定があることもあります。
基本的には以下に示す内容を記載することが一般的であり、これにより過不足なく必要な情報を記載できます。
要件定義書に記載する内容例
- システムの目的や背景
- システムの利用者や関連する人物
- 機能要件（システム構成図・業務フロー図）
- 非機能要件（品質・性能・拡張性・セキュリティ)
- 移行・運用・保守要件
システムの目的や背景
まず要件定義書には、なぜそのシステムを必要とするのか、「システムの目的や背景」を記載します。こちらは文章や挿絵などを使って、できるだけわかりやすく記載します。
具体的には、以下の2点を記載します。
ポイント
- 顧客が課題としている業務上の問題
- 開発するシステムによって、どの様に改善するのか
言い換えれば、「顧客の感じている課題」をいかにして抽出し、わかりやすく記載できるかは、SEとしての腕の見せどころと言えます。
システムの利用者や関連する人物
「システムの利用者」や「関連する人物」を洗いだして記載します。これは個人名などではなく、役職や役割の意味です（なお、社内資料などでは、担当者を整理したりします）。
これをおざなりにすると、以下のような問題が生じかねなません。
- 業務上の手続きに「もれ」が生じかねない
- 「誰が利用するか」を正しく想定しなければ、
- システムに過不足が生まれかねない
- ドキュメント（操作説明書や保守運用説明書）に過不足が生まれかねない
- 教育・訓練の期間や、移行期間に過不足が生まれかねない
また場合によってはシステム化することで影響を受ける社員などが、それに反発をすることもあります。こうした例の多くは、ベンダー側（要はSEの所属する会社側）の不手際により、関連する社員への説明が不足している場合に起こります。
要件定義書に関連する人物をもれなく記載し、該当する社員に理解を得ることで、こうした問題を軽減できる効果も期待できるのです。
機能要件 - システム構成図
機能要件は主に「システム構成図」と「処理フロー図」を作成します。システム構成図とは、下記に挙げる内容を示した「システムの全体像を示した概念図」です。
ポイント
- 使用するコンピュータ
- 通信回線
- 導入するソフトウェア
機能要件 - 業務フロー図
業務フロー図は、顧客が業務を遂行するための工程や作業を図に示したものです。ポイントは「業務フロー図」を、システム導入の前と後で「両方作成すること」です。
ポイント
- 業務上のどこに問題があるのか
- システム開発し導入することで、業務がどう改善するのか
大規模なシステムなどでは何十ページにも業務フロー図が及ぶこともあるため、片方のみに留めることも多くあります。
非機能要件（性能/拡張性/セキュリティ)
要件定義書には、作成する機能そのもの以外にも、記載が必要な項目があります。
例えば、システム完成後に提供されるサービスとは別に、保守やメンテナンスに関わる要件として「1回/週のバックアップ」や「定期的なログファイルの世代管理」など、「非機能要件」と呼ばれるものがその一つです。
非機能要件
- 性能：どの程度の利用者が一斉に利用できるのか
- 拡張性：システムの構成やバージョンアップなどを、どの程度可能にするか
- セキュリティ：通信の暗号化や、ウィルス対策ソフトの導入、
- 他（ユーザビリティやアクエシビリティなどを記載する場合もある）
この非機能要件は、主に顧客の規模や、導入するシステムの構成に依存します。作成したシステムの納品時には、これらの項目を全て満たしていなければならず、非機能要件を正しく見積もることは、SEの役目となります。
移行・運用・保守要件
要件定義書には、移行要件や運用要件に、保守要件なども記載します。
移行要件とは、すでに顧客が使用しているシステムがある場合、それを開発したシステムへ移行する場合の仕組みやその手順、そのための教育内容などのことです。
新規システムの場合、顧客がはじめて使用するシステムですので、そのシステムの習熟には時間がかかります。
運用要件は、そのシステムを安定的に動作させるために、下記の内容を定義したものです。
運用要件のポイント
- どのような体制が必要か
- どのような活動が必要か
保守要件も似ていますが、こちらは下記のポイントを目的とします。
保守要件のポイント
- 瑕疵担保責任などの所在を明確にする
- システムの不具合発生時の対応方法の記載
