要件定義書 テンプレート。 [文書]テンプレートの無料ダウンロード: システム開発の仕様書その他IT・PCに関するテンプレート

ダウンロード

要件定義書 テンプレート

はじめに 要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。 ゆえに、要件定義書には 「業務要件」と 「システム要件(機能と非機能)」の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やソフトウェアのバージョンアップにおける要件を記載する。 継続性要件 「信頼性要件の可用性」と同じ意味合いだが、こちらは大規模災害時における復旧目標時間や、データのバックアップについて記載する。 予備システムを別拠点に準備しておき、災害発生時に切り替える…というような冗長性具体的に書く場合もある。 情報セキュリティ要件 開発するシステムが満たすべきセキュリティの要件を記載する。 具体的には、.

次の

無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき

要件定義書 テンプレート

プロジェクト管理用 スケジュール管理などのプロジェクト管理用のテンプレートはなかなかないのですが、プロジェクト管理の補助となるようなテンプレートを用意しました。 プロジェクト管理ツールは、別記事の「」をご参照ください。 課題管理表 システム開発における課題管理を管理する課題管理表です。 完了した課題はグレーアウトするなどの工夫がされています。 日次スケジュール 日次スケジュールのテンプレートです。 土日を入力すると自動で色付けされます。 祝日などの少々こったことがしたい場合は別記事にある「」を使用してください。 月次スケジュール 月次スケジュールのテンプレートです。 1ヶ月を4週間で管理します。 とりあえず半年分作成してありますので、ご自由に加工してください。 各開発工程用 各開発工程で利用するテンプレートになります。 要件定義書 要件定義書のテンプレートです。 更新履歴や未決事項のシートも用意してあるので活用してください。 外部設計書 外部設計書のテンプレートです。 更新履歴や未決事項のシートも用意してあるので活用してください。 内部設計書 内部設計書のテンプレートです。 更新履歴や未決事項のシートも用意してあるので活用してください。 単体テスト仕様書・報告書 単体テスト仕様書・報告書のテンプレートです。 単体テスト修正内容報告書 単体テスト修正内容報告書のテンプレートです。 単体テスト仕様書・報告書とセットで使用します。 結合テスト仕様書・報告書 結合テスト仕様書・報告書のテンプレートです。 結合テスト修正内容報告書 結合テスト修正内容報告書のテンプレートです。 結合テスト仕様書・報告書とセットで使用します。 システムテスト仕様書・報告書 システムテスト仕様書・報告書のテンプレートです。 システムテスト修正内容報告書 システムテスト修正内容報告書のテンプレートです。 システムテスト仕様書・報告書とセットで使用します。 その他 その他用途で使用できるテンプレートになります。 議事録 議事録のテンプレートです。 作業計画・報告書 作業計画・報告書のテンプレートです。 おわりに とりあえず必要となると思われるシステム開発テンプレートは提供できたと思うのですがいかがでしょうか。 今後も必要なものがあれば追加できればと思います。 スポンサーリンク.

次の

システム開発の提案依頼書(RFP)・要求定義・要件定義の違いとは

要件定義書 テンプレート

毎度書いてるのでテンプレートをここに書き起こします、ご自由にご利用ください。 はじめに 誰が何をどのように求めているのか、これをまずは整理してみます。 要件定義書=5W1Hを語るドキュメントです。 下記をご参考までに。 5W1H なにをする 備考 Who 登場人物を整理 各登場人物と責任を明確化、判断する人いないプロジェクトは燃える。 What 何を作るのか整理 口頭は危険!を見て。 When いつまでにやるのかを整理 時間に限りがある場合は・・やれることも限られます Where 範囲・スコープを整理 範囲決めないと、ここも後でもめます。 本当に始めに決めないともめます。 Why そもそもどうして作るのかを整理 共通認識大切 How どうやって作るのかを整理 環境や、簡単なロジックやらやら 要件定義書 ドキュメントのバージョン管理 更新がある度に、何をどうして更新し、だれがその更新内容を承認したのか記載してください。 概要 関係メンバー全員、誰が読んでもわかるように、今回開発するモノの概要をここに記載してください。 システム構成図 ここにシステムの構成図を、一目でシステムの構成がわかるといいです。 データと業務のフローがカバーされているといいかも。 背景 なぜ開発することになったのかここに記載。 お客さんも要求する事がミッション達成に寄与しない場合もありますので、ただ受けるよりもここで背景をちゃんと理解して正しアドバイスをしてあげられるといいですね。 定義 これから使う専門用語はここで簡単に説明しておきましょう。 最後でもいいかも? 2. 業務要件 A. 業務フロー ここに業務フローを1Pでまとめてみます。 フロー(流れ)が一目でわかるといい。 業務を行う人たちをグループ化して、フローを書いてみる。 規模 業務の規模をここに定義、どれぐらいの規模の業務を想定していますか? C. 時期・時間 業務フローに関しての時期と時間をここに定義。 時間軸大切、これを定義してください。 指標 業務フローでの指標を定義。 範囲 システムに関連する範囲をここで定義。 システムに関係ないことは・・関係ないので。 機能要件 A. 機能 ここに機能を大区分、中区分、小区分みたいにブレイクダウンしてください。 開発案件によってここはだいぶボリュームあるかも。 画面 細かいことは外部設計書に記載、もしくはここは外部設計書。 情報・データ・ログ データ項目、処理方法などを記載。 どんなデータを保存するの? D. 外部インタフェース 外部インターフェイスを定義して記載。 入力される項目なども。 非機能要件 A. ユーザビリティ及びアクセシビリティ 誰がどう使えればいいのか、ここに定義して記載。 なんとなく・・つかいずらいみたいなを回避。 システム方式 構成をここに定義。 規模 想定規模をここに記載。 性能 性能に関する事項+閾値をここに記載。 信頼性 信頼性に関する事項をここに記載。 拡張性 拡張性に関する事項をここに記載。 上位互換性 バージョン対応などなどをここに記載。 前のバージョンにどうやって対応するのか。 継続性 冗長性などなどここに記載。 セキュリティー要件 A. 情報セキュリティ 必要とされるセキュリティーレベルをここに記載。 稼働環境 環境に関してここに記載。 要されるセキュリティーを見てから最適な環境を決めましょう。 テスト テストに関してここに記載。 テストは(も)お金がかかりますからね。 移行要件 A. 移行 移行のプロセス、タイミングなどをここに記載。 引継ぎ 引継ぎ業務などをここに記載。 運用要件 A. 教育 運用・利用・活用方法の教育など。 運用 運用体制、運用業務をここに記載。 保守 保守に関して記載。 誰がどうやるのか。 保守に関するSLAはを参照してください。

次の