[Doc] 要件定義書テンプレート・要件定義書の書き方

2023/03/27 GPT補完入れました。

毎度書いてるのでテンプレートをここに書き起こします、ご自由にご利用ください。
ここにワード版のテンプレートが置いてありますので自由にお使いください。　

(GPT補完)

要件定義とは、あるシステムや製品に求められる機能や性能、制約条件などを明確に定める作業のことです。つまり、ユーザーが望む機能や要件を明確に整理し、それを基にシステム開発や製品開発を進めるための基本的な作業です。要件定義を適切に行わないと、ユーザーの期待に沿わない製品やシステムが出来上がったり、コストや期間の増加などの問題が生じることがあります。

はじめに

誰が何をどのように求めているのか、これをまずは整理してみます。要件定義書＝5W1Hを語るドキュメントです。下記をご参考までに。

5W1H	なにをする	備考
Who	登場人物を整理	各登場人物と責任を明確化、判断する人いないプロジェクトは燃える。
What	何を作るのか整理	口頭は危険！顧客が本当に必要だったものを見て。
When	いつまでにやるのかを整理	時間に限りがある場合は・・やれることも限られます
Where	範囲・スコープを整理	範囲決めないと、ここも後でもめます。本当に始めに決めないともめます。
Why	そもそもどうして作るのかを整理	共通認識大切
How	どうやって作るのかを整理	環境や、簡単なロジックやらやら

要件定義書

ドキュメントのバージョン管理

更新がある度に、何をどうして更新し、だれがその更新内容を承認したのか記載してください。

例)

バージョン	日付	変更内容	担当者
1.0.0	2021-07-12	××の要件変更がされたため、○○部分追記ました。	鈴木

(GPT補完)

下記ドキュメントバージョンに関する注意点です。

1. バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。

2. 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。

3. ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができます。

4. 変更の承認手順を設ける：誰でもドキュメントを変更できるようにしてしまうと、誤った変更や重複した変更が発生する可能性があります。そのため、変更を承認するための手順を設け、変更の正当性を確認する必要があります。

5. バックアップを定期的に取得する：ドキュメントは大切な情報を含んでいるため、バックアップを定期的に取得することが重要です。それにより、何らかの不具合が発生した場合にも、過去のバージョンに戻すことができます。

1. 概要

関係メンバー全員、誰が読んでもわかるように、今回開発するモノの概要をここに記載してください。

A. システム構成図

ここにシステムの構成図を、一目でシステムの構成がわかるといいです。データと業務のフローがカバーされているといいかも。

↓クラウドで構成組んでいる方には便利なリンク

AWS使っている方はこちらのアイコンを使えます。
https://aws.amazon.com/jp/architecture/icons/

Azure使っているかたはこちらのアイコン使えます
https://docs.microsoft.com/ja-jp/azure/architecture/icons/

(GPT補完)

こちらシステム構成図作成時の一般的な手順です。

1. 概要を描く：まず、システム全体の概要を描きます。それには、システム全体の構造や機能、ユーザーとの接点などを含めます。

2. モジュールを定義する：次に、システム内にあるモジュール（機能の単位）を定義します。モジュールを決めることで、システム内の各機能の役割や関係性が明確になります。

3. モジュールの関係を描く：モジュール同士の関係を描きます。それによって、モジュールの役割や情報の流れが明確になります。

4. ハードウェアを描く：システム内で使用されるハードウェア（サーバーやネットワーク機器）を描きます。それによって、システムの物理的な構造が明確になります。

5. インタフェースを描く：システム内で使用されるインタフェース（APIやデータベース）を描きます。それによって、システム同士のやりとりやデータの流れが明確になります。

6. テキストで説明する：最後に、システム構成図をテキストで説明します。説明文には、システム全体の構造や機能、各モジュールの役割や関係性、ハードウェアやインタフェースの詳細などを記述します。

B. 背景

なぜ開発することになったのかここに記載。お客さんも要求する事がミッション達成に寄与しない場合もありますので、ただ受けるよりもここで背景をちゃんと理解して正しアドバイスをしてあげられるといいですね。

(GPT補完)

1. 背景についての共通理解を持つ：要件定義書を作成する前に、プロジェクトのステークホルダーや関係者と共通理解を持つことが重要です。システムの必要性や問題点について、関係者と議論し、共通認識を得ることが大切です。

2. 背景を明確にする：背景については、なるべく明確に記述するようにしましょう。具体的な事実や数値、実際の事例などを引用することで、背景をより具体的に伝えることができます。

3. ビジネス目標を示す：システムの背景には、プロジェクトのビジネス目標を示すことも重要です。そのシステムを導入することで、どのようなビジネス効果が期待できるのか、具体的な数字や目標を明確にすることで、プロジェクトの優先順位や進捗管理がしやすくなります。

4. 背景と要件の関係を明確にする：背景と要件定義との関連性を明確にすることも大切です。具体的には、どのような問題を解決するために、どのような要件が必要なのか、などを明確に記述することで、要件定義書の全体像がより明確になります。

C. 定義

これから使う専門用語はここで簡単に説明しておきましょう。

2. 業務要件

(GPT補完)

業務要件とは、ある業務を遂行するために必要な機能や制約、仕様など、業務に関する要件のことを指します。具体的には、業務のプロセスや手順、データの入力や出力の仕様、システムの性能や安全性に関する要件などが含まれます。

業務要件は、その業務を遂行する上で必要不可欠な要素であり、業務プロセスやシステム開発の指針となるものです。業務要件は、業務プロセスを最適化することや、システムの開発・導入・運用において問題を回避することにつながります。

業務要件は、業務プロセスやシステムの開発・導入・運用の段階で定義されます。業務要件定義のプロセスでは、業務を行う上で必要な要件を明確にし、それらをシステムに反映させるための仕様を決定することが重要です。業務要件定義のプロセスを十分に行い、正確かつ明確な業務要件を定義することで、システム開発の効率性を高め、システムの品質を確保することができます。

A. 業務フロー

ここに業務フローを1Pでまとめてみます。フロー（流れ）が一目でわかるといい。業務を行う人たちをグループ化して、フローを書いてみる=業務フロー図。

(GPT補完)

1. 業務の範囲を定義する: 業務フロー図を作成する前に、業務の範囲を明確に定義する必要があります。どの業務プロセスに焦点を当てるのか、業務の主なステップは何かを確認してください。

2. ステップを列挙する: 次に、業務プロセスに関連するステップを列挙し、それらの順序を決定します。ステップは、図に表示される順番通りに実行されます。

3. シンボルを選択する: 業務フロー図に使用するシンボルを選択します。たとえば、開始や終了を示す矢印、各ステップを示す矩形、決定を示す菱形などがあります。

4. ステップを配置する: 選択したシンボルを使って、業務プロセスの各ステップを図に配置します。ステップを表す矩形を描き、矢印を使ってステップ間のつながりを示します。

5. ステップの詳細を記入する: 各ステップについて、詳細を追加します。たとえば、ステップで実行されるタスクの説明、必要な情報のリスト、次のステップに進むための条件などを示します。

6. ステップのループや分岐を追加する: 一部のステップは、特定の条件下で何度も実行される場合があります。このような場合、ステップのループを示すために矢印を使用するか、ステップの分岐を示すために菱形を使用することができます。

B. 規模

業務の規模をここに定義、どれぐらいの規模の業務を想定していますか？

(GPT補完)
業務プロセスの規模に関する情報を業務フロー図やワークフロー図などで示し、その図中に規模に関する情報を追加できます。例えば、業務プロセスの中で処理されるデータ件数や利用者数、取り扱う商品数や取引回数などを示すことができます。

C. 時期・時間

業務フローに関しての時期と時間をここに定義。時間軸大切、これを定義してください。

(GPT補完)

1. 業務フロー図中に時間や期間を示す: 業務フロー図中に、業務の各段階における期間や時間を示すことができます。たとえば、業務プロセスの各ステップに関連する日数、時間、またはその他の期間情報をアイコンやシンボルなどで示すことができます。

2. テキストで時間や期間を記述する: 業務フロー図外に、各段階における期間や時間について、詳細に説明するテキストを記述することもできます。たとえば、業務の各ステップに関連する期間を記載し、それがどのように計算されたのか、あるいはその期間がどのように定められたのかを説明することができます。

3. スケジュール表を作成する: 業務フローの各ステップに関連する期間をまとめたスケジュール表を作成することもできます。スケジュール表には、業務プロセス全体の期間だけでなく、各ステップの期間、ステップ間の待ち時間などを含めることができます。

D. 指標

業務フローでの指標を定義。

(GPT補完)

1. 業務フローの指標は、業務プロセスの効率性や改善のためのベンチマークとなる数値や定量的なデータのことです。具体的には、以下のような指標があります。

2. サイクルタイム：業務プロセスの開始から終了までにかかる時間のことで、ステップごとに計測することができます。

3. 処理能力：業務プロセスが単位時間あたりに処理できる業務量を示す指標で、例えば、1時間あたりに処理できる申請書の数などを計測します。

4. エラー率：業務プロセスで発生するエラーの数を、処理された業務数の割合で表したものです。

5. 待ち時間：業務プロセスで発生する待ち時間の長さを表します。待ち時間が長い場合は、業務プロセス全体の効率性が低下する可能性があります。

リードタイム：業務プロセスが開始されてから完了するまでの期間を示す指標で、サイクルタイムとは異なり、業務プロセス中に発生する待ち時間を含みます。

E. 範囲

システムに関連する範囲をここで定義。システムに関係ないことは・・関係ないので。

(GPT補完)

システム範囲とは、システム開発や情報システム運用において、対象とするシステムの範囲や境界を明確にすることを指します。システムの範囲を定義することで、どのような機能を含め、どのような外部システムやユーザーとのインターフェースが必要かを明確にすることができます。

システムの範囲は、主にシステム開発や情報システム運用におけるプロジェクトの計画・設計フェーズで定義されます。システムの範囲を定義するためには、システムの目的や要件、利用者、外部システムとのインターフェース、利用環境などを分析・把握し、範囲を決定します。また、システムの範囲は、プロジェクトの範囲にも影響を与えることがあります。

システムの範囲を明確に定義することで、システム開発や情報システム運用において、システムの仕様や機能、外部システムとのインターフェースを明確にすることができます。これにより、システム開発や運用においての課題や問題点を明確にし、システムの品質や利便性を向上させることができます。

3. 機能要件

A. 機能

ここに機能を大区分、中区分、小区分みたいにブレイクダウンしてください。開発案件によってここはだいぶボリュームあるかも。ここでは機能の区分がメインとなります。

(GPT補完)

機能を分類することで、システムが提供すべき機能を明確にすることができます。たとえば、顧客管理機能や在庫管理機能など、それぞれの機能を分類することができます。

B. 画面

細かいことは外部設計書に記載、もしくはここは外部設計書。

C. 情報・データ・ログ

データ項目、処理方法などを記載。どんなデータを保存するの？

D. 外部インタフェース

外部インターフェイスを定義して記載。入力される項目なども。

4. 非機能要件

A. ユーザビリティ及びアクセシビリティ

誰がどう使えればいいのか、ここに定義して記載。なんとなく・・つかいずらいみたいなを回避。

例)
3クリック以内に決済完了ページにたどり着く必要がある

B. システム方式

構成をここに定義。

C. 規模

想定規模をここに記載。

D. 性能

性能に関する事項＋閾値をここに記載。

E. 信頼性

信頼性に関する事項をここに記載。

F. 拡張性

拡張性に関する事項をここに記載。

G. 上位互換性

バージョン対応などなどをここに記載。前のバージョンにどうやって対応するのか。

H. 継続性

冗長性などなどここに記載。

5. セキュリティー要件

A. 情報セキュリティ

必要とされるセキュリティーレベルをここに記載。

下記を記載

• アクセス制御方法
• アクセス認証方法
• データの暗号化
• ウィルス対策
• 修正ソフトウェア
• 侵入・攻撃対策
• その他利用制限
• 不正接続対策
• 外部媒体保存制限（運用ポリシー）

B. 稼働環境

環境に関してここに記載。対応しているブラザなど。要されるセキュリティーを見てから最適な環境を決めましょう。

C. テスト

テストに関してここに記載。テストは（も）お金がかかりますからね。下記を少なくても含んでください。

• 実行するテストタイプに関して、機能テスト、ユーザビリティテスト、負荷テスト、セキュリティテスト
• 担保する範囲とテスト範囲の定義（定義してテストが担保する範囲をカバーしていることを確認）
• テスト環境、だれが行うのか
• OKとNGの定義
• 使用するツール
• テストデータ、テストデータはどんなものか、どのように用意されるのか

6. 移行要件

A. 移行

移行のプロセス、タイミングなどをここに記載。

B. 引継ぎ

引継ぎ業務などをここに記載。

7. 運用要件

A. 教育

運用・利用・活用方法の教育など。

B. 運用

運用体制、運用業務をここに記載。

C. 保守

保守に関して記載。誰がどうやるのか。 保守に関するSLAはSLAの書き方を参照してください。