要件定義書の書き方
- 作成日時：
- 最終更新日時：
- Categories： others
- Tags： 初心者向け スタートアップシリーズ
開発者になるために必要な要件定義書の書き方と必要なものを解説する。
そもそも要件定義とは？
システムを作るために決めるべきこと。
とりわけ、システムにおける5W1Hに基づいて、取り決めを行う必要がある。
この取り決めが曖昧であれば、受注者と顧客間での認識に食い違いが生まれる。
要件定義書に必要なもの
要件定義書に正解はない。
必ずしも下記の全ての項目を作る必要はない。必要に応じて省略し、簡潔に済ませることもわかりやすくするためには重要である。
また、下記では足りない場合もある。必要に応じて書き足すなどの対処が必要になる。詳細は本記事末尾に書かれた参照元を参考に。
- 業務要件
- 背景
- 目的
- 範囲
- 機能要件
- システムの構成図
- 画面一覧
- 画面構成図
- テーブル一覧
- テーブル関連図(ER図)
- ネットワーク構成図
- 非機能要件
- 性能
- セキュリティ
- 移行
- 運用
- 保守
とりあえず上記のように、業務要件、機能要件、非機能要件の3つを押さえておくと良いだろう。
業務要件
そのシステム開発を行うに至った背景、システムを利用するユーザー、システム化前と後でどう変わるのかなどを取り決める。
ここで顧客との齟齬が生まれると、望んでいないものができあがってしまう。
顧客とのヒアリングの際には、なるべく要望の本質を掴むようにして、自分本意な提案等を押し付けないようにすることが重要である。
背景
システム化をするに至った背景、現状において発生している問題をまとめておく。
例えば、手作業で行っているため時間がかかっている、人為的なミスが発生しているなどがある。
目的
システム化の狙い、何を目指しているのかを決める。
システム化によって得られる効果などをまとめる。
範囲
システム化が影響する範囲を取り決める。
機能要件
成果物に関することを取り決める。
例えば、UIはどうするとか、DBの構造はこうするとか等。
システムの構成図
システムを実現する上で必要な要素をまとめる。
ハードウェアの構成、ネットワークの構成、ソフトウェアの構成、アプリケーションの構成等をここで取り決める。
使用するOSやミドルウェア、ネットワーク機器やハードウェア機器の機種もここで決める。
画面一覧
システムを実現するために必要になる画面をまとめる。
例えばECサイトであれば、ログイン画面、商品検索画面、商品個別画面、注文画面、注文履歴画面などがある。
画面から画面へ遷移する流れも書いていく。
画面構成図
画面に表示する具体的な内容、UIをここで決める。
ワイヤフレームで書いておくと良いだろう。後述のdiagrams.netも有効。
テーブル一覧
DBのテーブルをここでまとめる。
記録する内容、テーブルの概要を書く。
テーブルに記録するデータを誰に対して公開するか、秘匿にする必要があるかなどもここで決めておく。
テーブル関連図(ER図)
テーブル間の関連を決めておく。
これが後のDBにおけるテーブル間の1対多、多対多のリレーション構築に繋がる。
非機能要件
非機能要件にはシステムの機能面ではない部分についてまとめる。
ハードウェアやソフトウェアの性能、可用性(どれだけ動いていられるか)と信頼性(どれだけ壊れにくいか)。拡張性や運用・保守、セキュリティなども含める。
使いやすさ(ユーザビリティ)、操作しやすさ(アクセシビリティ)なども含む。
性能
ハードウェアとソフトウェアの性能をまとめる。
レスポンスがどれぐらいの速度か、それを実現させるための性能はどれだけ必要かも決めておくと良いだろう。
性能の拡張性なども考慮する。例えば、ハードウェアにディスクを追加する際、どれだけ追加できるか等。
セキュリティ
システム利用時における認証方式(多要素認証、CAPTCHAを使うなど)、パスワードの条件などを取り決める。
システムを利用する際、その情報を公開する範囲も取り決める。
想定される脅威やその対処法も決める。
移行
システム移行の手順と期間等を取り決める。
運用
システムのバックアップやサーバーの死活を監視するなどの業務の取り決めを行う。
保守
システムの復旧に必要なコスト、時間等を取り決める。
要件定義書の作成に使えそうなサイト
diagrams.net (旧名:draw.io)
ブラウザから簡単にフローチャートを作ったり、誰にでもわかるように図を作って表現することができる。
文章だけでは伝わらない箇所があるので、このようなツールを使って図や表などで表現をしたい。
結論
以下参照元。