ITシステムの要件定義書作成イメージです。
| 目次 | 要件定義を行う |
| 要件定義書のイメージ / １．機能要件 / ２．非機能要件 | |
| プロジェクト計画書のイメージ |
要件定義を行う
- 要件を言語化して定義し要件定義書にまとめる。
- 対象の範囲を明確にする。
- 隠れた要求や暗黙の要求も明らかにする。
- 開発側(ベンダー等)が要件定義をリードする。
- 要件定義の完了時点で工数の見積もりができるようにする。
- 後工程の作業ができるようにする。
- 会議の合意内容は議事録をとり顧客側とベンダー側双方が承認し要件定義書に反映する。
要件定義書のイメージ
システム化の要件を機能要件と非機能要件でまとめます。
１．機能要件
実現したい要件です。
| 1 | システムの目的・背景・効果 | |
| 2 | システムの全体図と範囲 | システム化する範囲を明確にする。 ベンダー間連携が必要な箇所は範囲を明確にする。 |
| 3 | 現業務フロー | |
| 4 | 現状の課題と解決方針 | |
| 5 | 新業務フロー | |
| 6 | 機能要件一覧 | 機能を一覧にしてまとめる。工数見積に使用する。 |
| 7 | システム構成図、ネットワーク構成図、DFD等。 | |
| 8 | 画面要件 | |
| 9 | 帳票要件 | |
| 10 | データ出力要件 | CSV出力等。 |
https://ja.wikipedia.org/wiki/%E6%A9%9F%E8%83%BD%E8%A6%81%E4%BB%B6
２．非機能要件
機能以外の要件です。
| 可用性 | システムを継続的に利用可能とする要件 継続性、耐障害性の考慮、災害に対する方針、回復の方針 |
| 性能・拡張性 | システムの性能と拡張性の要件 業務データ量 通常・繁忙期を考慮する 性能目標値として画面応答まで何秒以内等定める 拡張性も検討する。 |
| 運用・保守性 | 運用時間帯を確認する。サービスの時間は24時間、月1回メンテ有り等 復旧時間、復旧範囲、冗長化を考慮 バックアップの方針、バックアップのデータ保持期間、計画停止ありなし 保守契約、運用監視、運用サポート方針を決める。 OS、アプリのアップデート。DBのバックアップ、 死活監視、ログ監視、リソース監視 |
| 移行性 | 移行時期と方法と対象を計画する。 データの種類(マスタ/データ)、対象件数を明らかにする。 |
| セキュリティ | アクセス利用制限、セキュリティ対策の検討、不正追跡・監視の方法、認証の方法、ログの取得と保存期間等検討する。 |
| 環境 | CO2排出量や消費電力。 耐震、重量、温度、騒音等。 |
https://ja.wikipedia.org/wiki/%E9%9D%9E%E6%A9%9F%E8%83%BD%E8%A6%81%E4%BB%B6
プロジェクト計画書のイメージ
プロジェクトを進めるための計画書。
| 1 | プロジェクトの概要・範囲 | プロジェクト概要、開発システム概要 |
| 2 | 体制/リソース予定/役割 | 役割分担を決める。人の名前を入れて責任をはっきりさせる。 |
| 3 | マイルストーン/スケジュール管理 | 各工程の定義と終了条件 |
| 4 | コミュニケーション管理 | 会議体(定例、個別)、議事録、課題管理 進捗管理(遅れた時の対応方法)、資料共有方法、TODO |
| 5 | リスク管理 | プロジェクトを進める上で想定されるリスクを洗い出す。 |
| 6 | 進捗管理 | 遅延、オンスケ、前倒し 全体に影響があるか |
| 7 | 課題管理 | 解決していな課題は明確にする |
| 8 | 変更管理 | 仕様変更が起きたときの取り決め |
| 9 | パートナー管理 | 会社名、契約形態、期間、作業場所 |
| 10 | 品質管理 | レビュー時の指摘項目数や単体結合テスト時のバグ数から品質の数値を算出する。 レビュー密度、不具合検出率。 |
| 11 | 納品物 | 納品物を定める。要件定義書、外部設計書、内部設計書、プログラム一式、試験計画書、試験成績書、 移行計画書、移行報告書、方式設計書（インフラ）、操作マニュアル、品質報告書 |
関連の記事