要件定義書 サンプル。 「要件定義書」の書き方とは?目的や機能要件・テンプレートも紹介

要求仕様書の書き方は?要求定義書の項目や要件例・テンプレートも

要件定義書 サンプル

はじめに 要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。 ゆえに、要件定義書には 「業務要件」と 「システム要件(機能と非機能)」の2つを書けばよく、具体的な記載内容は決められていない。 とはいえ、担当者の能力で記載内容が変わるようでは、システム品質に差が出てしまうことから、記載内容やテンプレートを整備している企業も多い。 まずは自社ルールを確認してみる良いだろう。 なお、要件定義書を書き上げるまでの途中成果物として作成する資料については、下記をご覧いただきたい。 要件定義書の目次(例) 1. 業務要件の定義 1-1. 業務概要 1-2. 規模 1-3. 時期・時間 1-4. 場所 1-5. 管理すべき指標 1-6. システム化範囲 2. 機能要件の定義 2-1. システム機能要件 2-2. 画面要件 2-3. 帳票要件 2-4. 情報・データ要件 2-5. 外部インターフェース要件 3. 非機能要件の定義 3-1. ユーザビリティ及びアクセシビリティ要件 3-2. システム方式要件 3-3. 規模要件 3-4. 性能要件 3-5. 信頼性要件 3-6. 拡張性要件 3-7. 上位互換性要件 3-8. 継続性要件 3-9. 情報セキュリティ要件 3-10. 情報システム稼働環境要件 3-11. テスト要件 3-12. 移行要件 3-13. 引継ぎ要件 3-14. 教育要件 3-15. 運用要件 3-16. 保守要件 書くことが多すぎて嫌になるかもしれないが、過去のプロジェクトから書ける内容も多いため、ゼロから全てを書き上げる必要はない。 関連記事: では、さっそく、要件定義書の書き方について、下記3つに分けて説明していこう。 業務要件の定義 2. 機能要件の定義 3. 非機能要件の定義 業務要件 業務要件には、主に下記6つを記載する。 1-1. 業務概要 1-2. 規模 1-3. 時期・時間 1-4. 場所 1-5. 管理すべき指標 1-6. システム化範囲 業務概要 業務の概要では、下記の4つを記載する。 1)背景と目的 2)用語の定義 3)業務の概要 4)現行システム概要 1)背景と目的 システム化が必要な背景と目的を簡潔に記載する。 これらは要件定義より前の「企画」の段階で整理されているはずなので、企画段階の資料をもとに書くと良いだろう。 なお、背景と目的がピンとこない人は下記のように考える理解しやすい。 例) 業務時期:月初から第三営業日までに実施 業務時間:9時〜17時 場所 システム化対象業務が関係する場所や組織について概要を記載する。 業務フローに対して、Where(どこで?どこに?)の観点で整理すると良いだろう。 管理すべき指標 システム化対象業務にて、管理すべき指標を記載する。 重要業績指標(KPI)で考えるとイメージしやすい。 KIPの例については、下記のサイトが参考になる。 システム化範囲 対象業務のシステム化範囲を明確に記載する。 文章だけだとどうしても伝わりづらいので、「1-1. 業務概要」の業務フローや現行システムと合わせて記載すると良いだろう。 機能要件 機能要件には、主に下記5つを記載する。 2-1. システム機能要件 2-2. 画面要件 2-3. 帳票要件 2-4. 情報・データ要件 2-5. 外部インターフェース要件 システム機能要件 今回開発するシステム機能について、機能一覧や機能構成図に全体像をまとめる。 システム機能一覧の項目(例) ・機能名 ・機能種別(画面、帳票、バッチ等) ・処理概要 ・利用者 など 見積りに影響するような難易度の高い機能については、詳細な説明を記載しよう。 (別紙でも良い) ここには開発する機能を全て列挙するため、運用保守や移行に関係する機能も含めること。 画面要件 画面要件では、画面一覧/画面遷移図/画面レイアウトなどに加えて、具体的な画面イメージを記載する。 帳票要件 画面要件と同じく、帳票一覧/帳票レイアウトなどに加えて、具体的な帳票イメージを記載する。 情報・データ要件 保管するデータ項目の一覧やデータ量の想定件数を記載する。 ER図などを用いて表現することも多い。 外部インターフェース要件 今回開発するシステムと処理連携やデータの授受を行う他システムを一覧にまとめる。 システム機能一覧の項目(例) ・外部インターフェース名 ・外部インターフェース概要 ・連携方式(バッチorオンライン) ・送受信区分 ・相手先システム ・送受信タイミング ・送受信条件(ファイル転送等) など データ連携手法の選定する際には、下記の記事が参考になる。 非機能要件 非機能要件には、主に下記5つを記載する。 3-1. ユーザビリティ及びアクセシビリティ要件 3-2. システム方式要件 3-3. 規模要件 3-4. 性能要件 3-5. 信頼性要件 3-6. 拡張性要件 3-7. 上位互換性要件 3-8. 継続性要件 3-9. 情報セキュリティ要件 3-10. 情報システム稼働環境要件 3-11. テスト要件 3-12. 移行要件 3-13. 引継ぎ要件 3-14. 教育要件 3-15. 運用要件 3-16. 保守要件 ユーザビリティ及びアクセシビリティ要件 システム利用者の種類や特性 今回開発するシステムの利用者について、ITリテラシーの水準を記載する。 利用者のITリテラシーが低い場合は、画面構成や操作方法をよりシンプルにする必要があるだろう。 ・可用性 「使いたいときに使えるか」の指標。 一般的には稼働率を記載する。 ・完全性 「データの欠損や不整合がないこと」の指標。 機器の破損への対策、ログの取得など、定性的な書き方となることが多い。 拡張性要件 利用者やデータ量の増加といった「性能の拡張性」や、「システム機能の拡張」における要件を記載する。 上位互換性要件 OSやソフトウェアのバージョンアップにおける要件を記載する。 継続性要件 「信頼性要件の可用性」と同じ意味合いだが、こちらは大規模災害時における復旧目標時間や、データのバックアップについて記載する。 予備システムを別拠点に準備しておき、災害発生時に切り替える…というような冗長性具体的に書く場合もある。 情報セキュリティ要件 開発するシステムが満たすべきセキュリティの要件を記載する。 具体的には、.

次の

超上流から攻めるIT化の事例集:要件定義:IPA 独立行政法人 情報処理推進機構

要件定義書 サンプル

こんにちは、Web事業部マネージャーのさささん(さっさん)です。 Web制作の現場ではプロジェクト開始時に「要件定義」の工程から作業を着手することが一般的です。 ただし、いきなり要件を定義するわけではなく、顧客にヒアリングしたうえで課題の整理、要求の整理をおこない、要件定義として落とし込みます。 私は新卒からシステム開発の現場にいたので、要件定義に対して抵抗はありませんでしたが、Web業界で活動するようになってから要件定義がしっかりおこなわれていないプロジェクトがあることに驚きました。 また、苦手というか、なにをすればいいのか分からない人たちがけっこういることに気づきました。 そこで今回は、「要件定義ってざっくりとなにをすればいいのか」をチェックリスト形式で紹介いたします。 実際に要件定義が必要な場面でぜひ活用してもらえればと思います。 要件定義すべきこと 1. 制作の背景と目的 1. 制作の背景 制作することに至った経緯を記述します。 制作の目的 制作の目的として、プロジェクトのゴールを記述します。 制作の目標 制作において達成すべき目標を記述します。 KGIやKPIがあればあわせて記述します。 例えばCMSを導入する場合は、公開画面と管理画面が存在することが分かるように図で示します。 プロジェクトについて 2. 作業スコープ(作業範囲) 制作者側の作業範囲のみではなく、プロジェクト全体の作業スコープを明確にします。 発注側(発注元)の作業スコープ• (例)定例会への出席• (例)ドメインの取得• (例)受け入れテスト• (例)委託先からの質問に対する回答• 受注側(委託先)の作業スコープ• (例)定例会への出席• (例)プロジェクト管理• (例)WBS作成• (例)要件定義書作成• (例)画面設計書作成• (例)デザイン作成• (例)本番サーバー環境構築• (例)テストサーバー環境構築• (例)テスト仕様書作成• (例)ブラウザ検証• (例)リリース手順書作成 2. プロジェクト体制 プロジェクト体制を図で示します。 関係する会社、部門、担当者、役割を明記します。 納品物 納品物を列挙します。 (例)サイトデータ一式• (例)サイト更新マニュアル(PDF形式) 2. 納品場所・受け渡し方法 納品物の納品場所や受け渡し方法を明記します。 (例)サーバー納品• (例)ブルーレイディスクに保存し手渡しによる納品 2. スケジュール スケジュールに関しては別添としましょう。 サイト要件 3. ターゲットユーザー 今回の制作物のターゲットとなるユーザーを明記します。 OSごとにどのブラウザを担保するか表形式で明記すると分かりやすくなります。 サイトマップ 制作物のサイトマップを図で示します。 もしドキュメント内に収まらない場合は別添とします。 システム要件 4. 機能要件 実装する機能を一覧で示すのが一般的です。 非機能要件 実装する機能以外の要件を定義します。 次の項目を観点として、それぞれ定義することをおすすめします。 (例)可用性• (例)性能・拡張性• (例)運用・保守性• (例)移行性• (例)セキュリティー 4. インフラ要件 ドメインやSSLサーバー証明書、ネットワーク、サーバー環境について定義します。 項目例を列挙します。 (例)契約先のIDC、プラン• (例)サーバー、ネットワーク構成図• (例)ドメイン取得先、ドメイン名• (例)SSL証明書取得先、種類 4. 技術要件 開発言語や使用するフレームワークについても定義しておきます。 (例)開発言語• (例)プラットフォーム• (例)ミドルウェア• (例)通信プロトコル• (例)ソフトウェアフレームワーク• (例)オープンソースソフトウェア• (例)バージョン管理 5. その他 5. 用語の定義 プロジェクト独自で使われる言葉があれば、用語として定義し一覧化します。 参照資料 事前に発注元から資料をご提供いただいており、要件定義の参考とした場合は、それらの資料名やファイル名(版数)を一覧にしてまとめます。 まとめ いかがだったでしょうか? 具体的にどのようなことを記述するのがいいかは、プロジェクトメンバーに協力していただければと思っています。 まずはそれをまとめるために要件定義とはどんなことを記述する必要があるか知っていただき、お役に立てればと思いました。 今回は以上です。

次の

ミスなくモレなく見やすい「要件定義書」の書き方 (2/3):ユーザーの要件には「ウソ」がある?

要件定義書 サンプル

はじめに 要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。 ゆえに、要件定義書には 「業務要件」と 「システム要件(機能と非機能)」の2つを書けばよく、具体的な記載内容は決められていない。 とはいえ、担当者の能力で記載内容が変わるようでは、システム品質に差が出てしまうことから、記載内容やテンプレートを整備している企業も多い。 まずは自社ルールを確認してみる良いだろう。 なお、要件定義書を書き上げるまでの途中成果物として作成する資料については、下記をご覧いただきたい。 要件定義書の目次(例) 1. 業務要件の定義 1-1. 業務概要 1-2. 規模 1-3. 時期・時間 1-4. 場所 1-5. 管理すべき指標 1-6. システム化範囲 2. 機能要件の定義 2-1. システム機能要件 2-2. 画面要件 2-3. 帳票要件 2-4. 情報・データ要件 2-5. 外部インターフェース要件 3. 非機能要件の定義 3-1. ユーザビリティ及びアクセシビリティ要件 3-2. システム方式要件 3-3. 規模要件 3-4. 性能要件 3-5. 信頼性要件 3-6. 拡張性要件 3-7. 上位互換性要件 3-8. 継続性要件 3-9. 情報セキュリティ要件 3-10. 情報システム稼働環境要件 3-11. テスト要件 3-12. 移行要件 3-13. 引継ぎ要件 3-14. 教育要件 3-15. 運用要件 3-16. 保守要件 書くことが多すぎて嫌になるかもしれないが、過去のプロジェクトから書ける内容も多いため、ゼロから全てを書き上げる必要はない。 関連記事: では、さっそく、要件定義書の書き方について、下記3つに分けて説明していこう。 業務要件の定義 2. 機能要件の定義 3. 非機能要件の定義 業務要件 業務要件には、主に下記6つを記載する。 1-1. 業務概要 1-2. 規模 1-3. 時期・時間 1-4. 場所 1-5. 管理すべき指標 1-6. システム化範囲 業務概要 業務の概要では、下記の4つを記載する。 1)背景と目的 2)用語の定義 3)業務の概要 4)現行システム概要 1)背景と目的 システム化が必要な背景と目的を簡潔に記載する。 これらは要件定義より前の「企画」の段階で整理されているはずなので、企画段階の資料をもとに書くと良いだろう。 なお、背景と目的がピンとこない人は下記のように考える理解しやすい。 例) 業務時期:月初から第三営業日までに実施 業務時間:9時〜17時 場所 システム化対象業務が関係する場所や組織について概要を記載する。 業務フローに対して、Where(どこで?どこに?)の観点で整理すると良いだろう。 管理すべき指標 システム化対象業務にて、管理すべき指標を記載する。 重要業績指標(KPI)で考えるとイメージしやすい。 KIPの例については、下記のサイトが参考になる。 システム化範囲 対象業務のシステム化範囲を明確に記載する。 文章だけだとどうしても伝わりづらいので、「1-1. 業務概要」の業務フローや現行システムと合わせて記載すると良いだろう。 機能要件 機能要件には、主に下記5つを記載する。 2-1. システム機能要件 2-2. 画面要件 2-3. 帳票要件 2-4. 情報・データ要件 2-5. 外部インターフェース要件 システム機能要件 今回開発するシステム機能について、機能一覧や機能構成図に全体像をまとめる。 システム機能一覧の項目(例) ・機能名 ・機能種別(画面、帳票、バッチ等) ・処理概要 ・利用者 など 見積りに影響するような難易度の高い機能については、詳細な説明を記載しよう。 (別紙でも良い) ここには開発する機能を全て列挙するため、運用保守や移行に関係する機能も含めること。 画面要件 画面要件では、画面一覧/画面遷移図/画面レイアウトなどに加えて、具体的な画面イメージを記載する。 帳票要件 画面要件と同じく、帳票一覧/帳票レイアウトなどに加えて、具体的な帳票イメージを記載する。 情報・データ要件 保管するデータ項目の一覧やデータ量の想定件数を記載する。 ER図などを用いて表現することも多い。 外部インターフェース要件 今回開発するシステムと処理連携やデータの授受を行う他システムを一覧にまとめる。 システム機能一覧の項目(例) ・外部インターフェース名 ・外部インターフェース概要 ・連携方式(バッチorオンライン) ・送受信区分 ・相手先システム ・送受信タイミング ・送受信条件(ファイル転送等) など データ連携手法の選定する際には、下記の記事が参考になる。 非機能要件 非機能要件には、主に下記5つを記載する。 3-1. ユーザビリティ及びアクセシビリティ要件 3-2. システム方式要件 3-3. 規模要件 3-4. 性能要件 3-5. 信頼性要件 3-6. 拡張性要件 3-7. 上位互換性要件 3-8. 継続性要件 3-9. 情報セキュリティ要件 3-10. 情報システム稼働環境要件 3-11. テスト要件 3-12. 移行要件 3-13. 引継ぎ要件 3-14. 教育要件 3-15. 運用要件 3-16. 保守要件 ユーザビリティ及びアクセシビリティ要件 システム利用者の種類や特性 今回開発するシステムの利用者について、ITリテラシーの水準を記載する。 利用者のITリテラシーが低い場合は、画面構成や操作方法をよりシンプルにする必要があるだろう。 ・可用性 「使いたいときに使えるか」の指標。 一般的には稼働率を記載する。 ・完全性 「データの欠損や不整合がないこと」の指標。 機器の破損への対策、ログの取得など、定性的な書き方となることが多い。 拡張性要件 利用者やデータ量の増加といった「性能の拡張性」や、「システム機能の拡張」における要件を記載する。 上位互換性要件 OSやソフトウェアのバージョンアップにおける要件を記載する。 継続性要件 「信頼性要件の可用性」と同じ意味合いだが、こちらは大規模災害時における復旧目標時間や、データのバックアップについて記載する。 予備システムを別拠点に準備しておき、災害発生時に切り替える…というような冗長性具体的に書く場合もある。 情報セキュリティ要件 開発するシステムが満たすべきセキュリティの要件を記載する。 具体的には、.

次の